Entornos y metodologías

Desarrollo

El metabuscador fue desarrollado desde cero, no hace parte de desarrollos previos, y está hecho en un lenguaje de programación abierto. Se apoya en herramientas de software.

Tecnologías y arquitectura

Para el FRONTEND:

Para el BACKEND:

✔️ Se utiliza Python para el desarrollo de los modelos de Machine Learnin. También es utilizado para identificar los valores de los metadatos y para el desarrollo de algunos script que se ejecutan en función de organizar las zonas geográficas y las líneas de tiempo.

✔️ Se tiene un script (runtime.py) que orquesta todo el flujo de tareas: los análisis textuales y las visualizaciones, la estandarización de los metadatos, la creación de los NGram, el etiquetado para que sean consultadas desde ElasticSearch, y también ejecuta tareas de limpieza. Dicho script se puede encontrar en:

sim-data-processing/-/tree/develop/procesado-general

✔️ Arquitectura orientada a servicios: la aplicación está dividida en frontend y backend, en el backend se encuentran los servicios que luego son consumidos por la aplicación. Esta arquitectura se pensó en función de reutilizar servicios para los distintos componentes que se van creando; adicionalmente, permite una identidad misional para todos los desarrollos de la Comisión de la Verdad. Según el equipo de ingenieros, la arquitectura obedece a las tendencias que existen actualmente para el desarrollo web, las cuales consisten en un backend escrito en microservicios (los desarrollos de la Comisión de la Verdad cuentan con servicios pequeños); y un frontend con un Framework de visualizaciones que consume esos servicios. El servicio más importante para la aplicación metabuscador es search.service.ts, el cual es llamado desde el frontend por el controladorsearch.js.

Dentro del repositorio, se encuentra una carpeta por cada servicio; se pueden encontrar en:

sim-backend-nest/-/tree/develop/src

Es importante tener en cuenta que el backend del metabuscador, aunque en su mayoría está desarrollado en función de servicios, tiene algunos componentes implementados bajo el modelo monolítico; esto es así debido a que el aplicativo se comenzó a desarrollar bajo este patrón. En la medida en que el desarrollo fue creciendo, se comenzó a implementar una arquitectura orientada a servicios, conservando algunas estructuras monolíticas que eran funcionales.

Los archivos que ejecutan los diferentes servicios son: para el backend main.ts y para el frontend app.js. Dentro del repositorio, se pueden encontrar en la ruta:

BACKEND: sim-backend-nest/-/tree/develop/src
FRONTEND: sim-frontend/-/tree/develop/src

✔️ Integración con ElasticSearch: la recuperación de información se hace a través del indexador ElasticSearch. El aplicativo crea un archivo JSON que agrupa los datos provenientes de MongoDB y las colecciones ResourcesGroup, Resources y Record en una sola estructura; es decir, cada ResourcesGroup se agrupa con sus Resources y estos, a su vez, con sus Record. El aplicativo está a nivel de Resource, esto quiere decir que crea un archivo JSON por cada Resource con sus respectivos Record. El archivo JSON es el que consulta luego el indexador. Para entender la arquitectura de la base de datos se recomienda visualizar Colecciones DB.

✔️ Integración de herramientas: la integración con lo que se produce desde las demás herramientas de la Comisión de la Verdad se realiza a través de procesos ETL. Se toman las bases de datos de cada una de las herramientas y se realiza una conversión de los datos a la estructura definida para el metabuscador (ResourceGroup, Resource, Record); la conversión que realizan las ETL genera la equivalencia necesaria para almacenar esos datos en MongoDB.

Las ETL van a las bases de datos que se quieren integrar, extraen la información de esas bases de datos, la transforma en la nueva estructura y, automáticamente, la carga en la base de datos de MongoDB.

Durante el tiempo de la Comisión de la Verdad, este proceso se ejecutó diariamente a media noche.

Las integraciones se realizan bajo la tecnología Pentaho Spoon.

Metodologías

  • Modelo atómico: bajo esta metodología se definen: páginas, organismos, moléculas y átomos, que luego pueden ser reutilizados en otros desarrollos. Todos los componentes del metabuscador desarrollado por la Comisión de la Verdad, usan esta misma estrategia con el fin de tener una estructura homogénea.

  • Programación Sprint Scrum:

    • Historias de usuarios

    • Definición de tableros y actividades (sprints)

    • Planeación y seguimientos

Esta metodología se adopta por las condiciones cambiantes de la Comisión. Scrum permite adaptarse a requerimientos cambiantes y permite tomar decisiones de manera rápida; adicionalmente, se nutre de la experiencia de usuario. En entornos de desarrollo, Scrum ha sido apropiada como una buena práctica.

Cuando se inició el desarrollo del metabuscador, se inició con unos lineamientos básicos que fueron cambiando, definiéndose y entendiéndose mejor; de allí la motivación de escoger Scrum frente a otras posibilidades. En últimas, permite presentar avances y versiones funcionales en un corto tiempo.

Buenas prácticas

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.

Última actualización