Entornos y metodologías
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
oTranscribe
Dataturks
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.
Página principal oTranscribe
El módulo de escucha se conecta a los WebService que tiene dispuesta la Dataturks API, para el envío y la recepción de información. En este sentido, desde el módulo se envía a Dataturks la transcripción y el árbol de etiquetado, para que se codifique el texto; y, una vez hecha la tarea, el módulo recoge nuevamente los resultados del etiquetado y los almacena. Se modificó la autenticación en Dataturks, para que este proceso se realice a través de usuarios con cuentas de correo electrónico de dominio comisiondelaverdad.co, y no con usuarios y claves propios de Dataturks.
Dataturks Document Annotations
En el modelo
entrevista_individual.php contiene las interconexiones que deben hacerse para el intercambio de información con Dataturks, a partir de la línea 5528.
entrevista_individual.php
El modelo
tesauro.php contiene una serie de funciones básicas de interacción, a partir de la línea 452: crear proyecto en dataturks, eliminar proyecto, subir archivo, etc. 
tesauro.php
Estas líneas se aprovechan en las entrevistas, particularmente en el modelo
entrevista_individual.php.
entrevista_individual.php
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:
✔
- 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:
Configuración de servidores.pdf
127KB
PDF
Configuración servidores
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:
Manual de instalación y configuración módulo de escucha.pdf
317KB
PDF
Manual de instalación y configuración
- 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.
Última actualización 1yr ago