Entornos y metodologías
Última actualización
Última actualización
El desarrollo es una solución completamente original, no hace parte de desarrollos previos. Tiene dos conexiones: una manual con oTranscribe (los transcriptores usan oTranscribe y la transcripción luego es cargada, de manera manual, en el módulo de escucha); y para la función de etiquetado se conecta, a través de un WebService, con Dataturks (solución que recibe las transcripciones y el árbol de etiquetas para la codificación del texto).
Lenguaje de programación PHP; versión 7.3
Framework Laravel; versión 5.5
jQuery (frontend); versión 3.5.1
PostgreSQL (backend); versión 11.12
Bootstrap (librería CSS); versión 4.6
Desde el módulo de escucha se descarga el audio de la entrevista. Manualmente, se carga a la plataforma oTranscribe; se descarga la transcripción en formato OTR, y vuelve a cargarse al módulo de escucha.
Simplicidad: la herramienta se diseñó bajo el principio de simplicidad y es mucho más simple mantener y operar un aplicativo MVC que uno orientado a microservicios. No existe la tarea extra de orquestación de servicios, y toda la funcionalidad se encuentra concentrada en un solo componente central. Por otra parte, el aplicativo es bastante simple y cuenta con pocas funcionalidades, por lo que no tiene mucho sentido descomponerlo en pequeños componentes (servicios).
Evolución: además de MVC, se utilizaron herramientas como agile (y no waterfall) que son más apropiadas para patrones de diseño MVC. Algo importante en este proyecto, es que nunca se tuvo claridad del alcance del mismo; es decir, no hubo una planeación inicial que permitiera intuir los alcances que hoy tiene. Al principio, se visualizó como una solución temporal ante los vacíos de la herramienta DataFile (que iba a cubrir la necesidad del resguardo de entrevistas). No se habían visualizado los temas de gestión (transcripción, etiquetado, tesauro), de seguridad (R-2, R-3, R-4) y de Casos e informes, etc. Todo el desarrollo de módulo de escucha obedeció a un proceso de cubrir necesidades que se iban descubriendo. Para utilizar arquitecturas como la de microservicios es necesario una comprensión amplia y mucho más exhaustiva de la herramienta a desarrollar.
Practicidad: el módulo de captura es la primera herramienta del SIM y muchas cosas no estaban listas: aún no estaba definido el tema de infraestructura, y TIC no había prestado nunca algún servicio de crear máquinas virtuales, instalar servicios, temas de soporte, etc. Adicionalmente, el módulo fue desarrollado por un solo programador, por lo que mantener un esquema de desarrollo monolítico es una ventaja.
Si se hubiera tenido un equipo más grande de desarrollo, una planeación y un conocimiento más amplio de todas las funcionalidades que tiene actualmente el módulo, y unos servicios de infraestructura más maduros, el desarrollo se hubiera pensado bajo una arquitectura más adecuada.
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 escucha, la Comisión de la Verdad pone a disposición el siguiente archivo:
Programación ágil
Programación Sprint Scrum:
Historias de usuario
Definición de tableros y actividades (sprints)
Planeación y seguimientos
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.
El modelo más importante y robusto del proyecto es entrevista_individual.php. Este modelo se reutiliza en los demás tipos de entrevista, aprovechando las lógicas que son comunes a todas ellas. Dentro de este modelo se encuentra también la lógica para las fichas, las estadísticas y la buscadora.
Hay dos servidores de aplicaciones que se sincronizan, para que el aplicativo no deje de funcionar si algún servidor presenta fallas.
A nivel de base de datos se tiene un clúster configurado master-slave, en el motor PostgreSQL.
Las búsquedas y consultas se resuelven a nivel de base de datos, usando el criterio técnico full text search.
Arquitectura orientada al patrón Modelo Vista Controlador (MVC): se desarrolló bajo esta arquitectura por tres motivos:
