Ref.
2026/DIYGIDLPTA/15491
Job offer type
Experts
Type of contract
Service contract
Activity sectors
Vocational training, Integration, Employment ; Engineering of development
Deadline date
2026/06/12 23:55
Duration of the assignment
Short term
Contract
Freelancer
Duration
10 meses
Desarrollo, implementación y gestión integral de la plataforma tecnológica «LAMARR App» (M/W)
Département Capital humain et Développement social - CHDS > Formation professionnelle, Insertion et Emploi
Published on : 2026/05/19
AMERICAS
EL SALVADOR
Mission description
II. Objetivo de la contratación
II.I. Objetivo General
Contratar a un proveedor especializado para el diseño, desarrollo, implementación, soporte y gestión técnica de la plataforma LAMARR App, asegurando la trazabilidad total del ciclo de vida de los participantes y la transparencia en la ejecución financiera y académica del proyecto.
II.II. Objetivos Específicos
• Desarrollar los módulos funcionales de seguimiento específico (PATH) y seguimiento transversal (SERA EF).
• Implementar un sistema automatizado de gestión de asistencias y liquidación de viáticos.
• Establecer mecanismos de control académico y de seguimiento a la empleabilidad en tiempo real.
• Garantizar la interoperabilidad de datos y la generación automática de reportes para la toma de decisiones estratégicas.
• Asegurar la protección de datos personales de los beneficiarios conforme a la normativa salvadoreña vigente y las buenas prácticas internacionales.
• Transferir el conocimiento técnico necesario al equipo de Expertise France para garantizar la sostenibilidad de la plataforma una vez finalizado el contrato.
III. Alcance del trabajo y requerimientos funcionales
III.I. Fases de Implementación
El proyecto se ejecutará en fases iterativas, priorizando un Producto Mínimo Viable (MVP) que incluirá los módulos críticos para la operación inicial. Las funcionalidades adicionales podrán ser desarrolladas en fases posteriores según la priorización conjunta entre el Product Owner de Expertise France y el equipo del proveedor. Cada fase culminará con una entrega validada por QA y con su respectivo desembolso, conforme al numeral XI.VI del presente documento.
III.II. Supuestos de Volumen y Escalabilidad
La solución deberá ser dimensionada considerando los siguientes volúmenes estimados de operación. Estos valores son referenciales y tienen como objetivo orientar a los proveedores en la definición de su arquitectura y propuesta económica:
|
Variable |
Valor estimado |
|
Participantes estimados en el programa |
2,000 |
|
Centros de Formación Profesional (CFPs) |
100 |
|
Usuarios administrativos (Operador, EF, CFPs) |
10 |
|
Usuarios concurrentes estimados |
200 |
|
Registros diarios de asistencia |
200 |
|
Volumen estimado de transacciones mensuales |
150,000 – 200,000 |
|
Volumen de almacenamiento de documentos (mensual) |
≈ 1.5 GB / mes (sólo documentos e imágenes) |
El proveedor deberá considerar estos volúmenes para garantizar que la solución sea escalable, mantenga un rendimiento adecuado y soporte el crecimiento del programa sin degradación significativa del servicio. Se espera que la arquitectura propuesta contemple mecanismos de escalabilidad horizontal o vertical según corresponda, así como buenas prácticas de gestión de datos y almacenamiento.
III.III. Arquitectura de la Solución
La arquitectura propuesta responde a un enfoque por capas, separando la presentación (web y móvil), la lógica de negocio (backend) y la capa de datos, con integración a servicios externos. Este esquema busca garantizar la escalabilidad, la mantenibilidad y la interoperabilidad con sistemas externos. El proveedor podrá proponer ajustes o mejoras a la arquitectura como parte de su propuesta técnica, manteniendo los principios definidos.
III.IV. Módulos
El proveedor deberá desarrollar e implementar una plataforma integral basada en los siguientes bloques de procesos:
A. Módulo PATH (Seguimiento Específico)
• Preselección
• Aplicación
• Autorización de uso de imágenes (Consentimiento informado)
• Revisión de video
• Entrevista preliminar
• Pruebas psicométricas
• Entrevista final a profundidad
• Activación
• Mentoreo
• Alineación
• Transformación
• Expansión
B. Módulo de Asistencia, Viáticos y Respaldo Administrativo
• Registro diario de asistencia
• Cobro semanal de viáticos
• Solicitudes de viáticos diferenciados
• Reportes y respaldo administrativo para desembolsos
• Autorizaciones y visualizaciones globales
C. Módulo de Evaluaciones y Desempeño Académico
• Registro de evaluaciones
• Control de calificaciones
• Reportes de evaluaciones
• Reportes de deserciones
• Registro y reportes académicos
• Autorizaciones y visualizaciones globales
D. Módulo de Empleabilidad
• Intermediación laboral
• Registro y reportes de empresas
• Registro y reportes CAPRO
• Seguimiento a la inserción laboral
• Seguimiento de registros y deserciones
E. Módulo de Justificación Administrativa y Liquidaciones
• Liquidaciones con Operadores y EF
• Visualización de desembolsos realizados
• Liquidaciones de viáticos con CFPs
F. Módulo SERA EF (Seguimiento Transversal)
• Seguimiento de registros y deserciones
• Seguimiento cuantitativo a procesos
• Satisfacción de la calidad
• Seguimiento cuantitativo a la inserción y retención laboral
• Seguimiento a indicadores
III.V. Definición de Épicas
Las siguientes épicas representan la traducción funcional de los módulos descritos anteriormente. Cada épica deberá descomponerse en historias de usuario priorizables dentro del Product Backlog.
ÉPICA 1: Enrolamiento y Registro de Postulantes
Descripción: Como postulante, deseo registrarme en la plataforma mediante mi documento de identidad, completar mi información personal y validar mi identidad, para iniciar el proceso de selección dentro del programa LAMARR.
Criterios de Aceptación:
• El sistema permite el auto-registro mediante documento de identidad.
• Se integra con un servicio externo para realizar prueba de vida (validación biométrica).
• Se registran los datos personales del usuario.
• Se crea el registro de autenticación (usuario/contraseña).
• Se realiza verificación de correo electrónico.
• El usuario queda en estado «Preinscripción».
• El usuario puede visualizar y acceder a las pruebas de selección disponibles.
• Se solicita y registra el consentimiento del usuario (uso de datos) previo a su interacción en el sistema.
• Se genera el documento de consentimiento digital.
ÉPICA 2: Gestión del Proceso de Selección
Descripción: Como evaluador, deseo gestionar el proceso de selección de postulantes mediante diferentes pruebas y evaluaciones, para determinar su elegibilidad dentro del programa. Estados del postulante: Preinscripción, En Evaluación, Rechazado, Activo (Matriculado).
Criterios de Aceptación:
• El sistema permite asignar postulantes a evaluadores.
• El sistema gestiona las etapas de evaluación previstas:
◦ Formulario de aplicación, configurable según centro de formación.
◦ Video de motivación, cargado por el postulante.
◦ Entrevista telefónica, con registro estructurado y validación de datos.
◦ Pruebas psicométricas, con integración o registro de resultados de herramientas externas (p. ej. PsicoSmart).
◦ Entrevista completa con guía estructurada.
• El sistema permite registrar observaciones en cada etapa.
• Se permite avanzar o rechazar postulantes en cualquier etapa.
• El sistema registra el historial completo del proceso.
• Al completar satisfactoriamente el proceso, el postulante pasa a estado «Matriculado/Activo».
• Se genera la carta compromiso al finalizar el proceso.
ÉPICA 3: Gestión de Servicios al Participante
Descripción: Como participante matriculado, deseo acceder a los servicios del programa para desarrollar mis habilidades técnicas, blandas y mejorar mi empleabilidad. Servicios incluidos: formación técnica, habilidades blandas, mentorías, simulador de empleo y actividades complementarias (charlas, conversatorios, red alumni).
Criterios de Aceptación:
• El sistema permite asignar servicios a participantes matriculados.
• El sistema registra el progreso del participante en cada servicio.
• Se visualiza el avance del participante de forma gráfica.
• El sistema permite gestionar mentorías:
◦ Asignación individual según disponibilidad.
◦ Modalidad híbrida (virtual/presencial).
• El sistema permite gestionar el simulador de empleo:
◦ Registro de simulaciones de entrevistas.
• El sistema permite gestionar potenciadores:
◦ Identificación de participantes elegibles.
◦ Asociación con beneficios (p. ej. viáticos).
• El sistema permite gestionar actividades complementarias:
◦ Registro de asistencia a charlas y eventos.
• El sistema permite adaptar los servicios según disponibilidad y reglas definidas por el programa.
ÉPICA 4: Gestión Académica
Descripción: Como centro de formación, deseo registrar y gestionar la información académica de los participantes para dar seguimiento a su desempeño.
Criterios de Aceptación:
• El sistema permite registrar asistencia diaria, calificaciones y expediente académico.
• Se registran resultados de evaluación inicial (entrada) y evaluación final (salida).
• El sistema permite generar reportes académicos.
• El sistema permite detectar riesgos de deserción.
• Se aplica regla de asistencia mínima (p. ej. 85%).
ÉPICA 5: Gestión de Asistencia y Viáticos
Descripción: Como operador, deseo gestionar la asistencia y el pago de viáticos de los participantes, para garantizar transparencia y control financiero.
Criterios de Aceptación:
• El sistema permite registrar asistencia por evento o jornada.
• Los centros de formación pueden crear eventos que habiliten registro de asistencia y cálculo de viáticos.
• El sistema calcula viáticos de forma semanal.
• El sistema evita la duplicidad de pagos (no doble turno).
• El sistema genera reportes de conciliación.
• Se elimina el proceso manual/offline de pago.
• Se permite visualizar total de asistencia y total de monto a pagar.
ÉPICA 6: Gestión de Deserción
Descripción: Como operador, deseo registrar y gestionar la deserción de participantes para controlar los indicadores del programa.
Criterios de Aceptación:
• El sistema permite registrar deserción de forma manual.
• Se genera documento de salida (IP-17).
• Se controla el cumplimiento de reglas como porcentaje mínimo de asistencia y porcentaje máximo de deserción permitido.
ÉPICA 7: Gestión de Documentos
Descripción: Como sistema, deseo generar y almacenar documentos clave del proceso para asegurar trazabilidad y cumplimiento.
Criterios de Aceptación:
• Se generan automáticamente el consentimiento informado y la carta compromiso.
• Los documentos se almacenan digitalmente.
• Los documentos se asocian al perfil del participante.
ÉPICA 8: Empleabilidad y Seguimiento Laboral
Descripción: Como operador, deseo dar seguimiento a la inserción laboral de los participantes para medir el impacto del programa.
Criterios de Aceptación:
• El sistema permite registrar las actividades de intención de búsqueda de empleo.
• Se registra la participación en actividades de empleabilidad.
• Se registra la inserción laboral en empresas.
• Se actualiza información periódicamente (3 a 6 meses).
• Se registran estados laborales: Activo, Deserción laboral, Ascenso.
• Se permite actualizar datos mediante formularios (p. ej. IC04).
• Se mantiene el historial de seguimiento laboral.
ÉPICA 9: Integraciones y Plataforma Tecnológica
Descripción: Como sistema, deseo integrarme con plataformas externas para mejorar la operación y la automatización.
Criterios de Aceptación:
• Integración con servicio de validación de identidad (prueba de vida) – requerido.
• Integración con Microsoft 365.
• Posibilidad de integración con SharePoint para gestión documental.
ÉPICA 10: Administración y Configuración del Sistema
Descripción: Como administrador del sistema, deseo gestionar y configurar los parámetros operativos, catálogos y reglas de negocio de la plataforma, para adaptar su funcionamiento a las necesidades del programa LAMARR sin requerir cambios de código.
Criterios de Aceptación:
• El sistema permite gestionar centros de formación (CFPs); usuarios y roles (EF, Operador, CFPs, Participantes); y catálogos de estados del postulante y participante.
• El sistema permite configurar formularios dinámicos por centro de formación, tipos de servicios y actividades, y parámetros del programa (p. ej. % mínimo de asistencia, reglas de deserción).
• El sistema permite definir reglas de viáticos (cálculo, restricciones, periodicidad) y reglas de elegibilidad para servicios (p. ej. mentorías, potenciadores).
• El sistema permite gestionar catálogos maestros (empresas, tipos de eventos, tipos de evaluaciones).
• Los cambios de configuración se aplican sin necesidad de despliegues técnicos y quedan registrados con trazabilidad.
ÉPICA 11: Reportes e Indicadores
Descripción: Como usuario de nivel operativo y estratégico, deseo visualizar y generar reportes e indicadores en tiempo real, para dar seguimiento a la ejecución del programa, la toma de decisiones y el cumplimiento de los indicadores ya definidos del proyecto.
Criterios de Aceptación:
• El sistema permite visualizar dashboards con indicadores clave: avance del PATH por participante, asistencia y ejecución de viáticos, indicadores de deserción, e inserción y retención laboral.
• El sistema permite generar reportes por participante, centro de formación (CFP), operador y programa completo (nivel EF).
• El sistema permite exportar reportes en formatos estándar (PDF, Excel u otros definidos).
• El sistema permite filtrar información por fecha, centro de formación, estado del participante y tipo de servicio.
• El sistema soporta la generación automática de reportes asociados a indicadores del proyecto (SERA EF) y a justificaciones administrativas y financieras.
• El sistema permite acceso diferenciado a reportes según el rol de usuario.
ÉPICA 12: Auditoría y Logs del Sistema
Descripción: Como administrador y entidad supervisora, deseo contar con mecanismos de auditoría y registro de actividades para garantizar la trazabilidad, la transparencia y el control sobre todas las operaciones realizadas en la plataforma.
Criterios de Aceptación:
• El sistema registra logs de actividad de usuarios, incluyendo creación, edición y eliminación de registros, cambios de estado de participantes y acciones sobre asistencia, viáticos y evaluaciones.
• El sistema permite consultar el historial de cambios por usuario, módulo y entidad (participante, centro, evento, etc.).
• El sistema registra eventos críticos: errores de aplicación, fallos de integración y accesos no autorizados.
• El sistema permite visualizar logs mediante interfaz administrativa.
• El sistema garantiza la integridad de los registros de auditoría (no modificables) y la persistencia de logs por un período definido.
• El sistema permite exportar logs para procesos de auditoría externa.
IV. Perfil de usuarios y accesos
La plataforma debe contemplar niveles de acceso diferenciados, gestionados mediante un esquema de control de acceso basado en roles (RBAC):
• Expertise France (EF): superadministrador con acceso a visualizaciones globales, autorizaciones y reportes de alto nivel.
• Operador: gestión de la ejecución territorial y supervisión de los CFPs.
• CFPs (Centros de Formación): carga de datos operativos, asistencias y calificaciones.
• Participantes: consulta de perfil, asistencia y seguimiento de su progreso.
V. Responsabilidades de gestión
Siguiendo la visión de gestión integral del proyecto, el proveedor deberá designar un equipo que asuma las siguientes funciones:
• Traducción de necesidades: convertir los requerimientos estratégicos de Expertise France en funcionalidades técnicas claras (Backlog), las cuales deben ser confirmadas por los usuarios de negocio y ratificadas por el Product Owner delegado por EF.
• Optimización de procesos: identificar cuellos de botella en los flujos de trabajo actuales y proponer soluciones digitales escalables.
• Metodología ágil: ejecutar el desarrollo bajo el marco de trabajo ágil Scrum, con entregas iterativas y demostraciones periódicas.
• Transferencia de conocimiento: documentar técnica y funcionalmente la solución y capacitar al equipo de Expertise France para garantizar la sostenibilidad post-contrato.
VI. Entregables clave
• Plan de Trabajo y Cronograma: detallando las fases de levantamiento de requerimientos, diseño, desarrollo, pruebas, certificación, liberación, estabilización y transición del servicio.
• Plataforma LAMARR App funcional: instalada y configurada en ambiente de producción, con sus respectivos ambientes de desarrollo y pruebas.
• Manuales de usuario y técnico: documentación completa para cada perfil de usuario y para el equipo técnico de soporte.
• Dashboard de indicadores: panel visual para la monitorización de los indicadores del proyecto.
• Colección de endpoints (API): colección viva (p. ej. Postman) que permita reproducir todos los escenarios validados en el backend.
• Plan de capacitación y traspaso: sesiones de capacitación al equipo de EF y entrega formal de credenciales, código y documentación.
Project or context description
I. Antecedentes y Contexto
I.I. El Proyecto LAMARR
El Proyecto LAMARR, titulado oficialmente «Competencias digitales y empleabilidad para jóvenes en El Salvador», es una iniciativa estratégica enmarcada en la agenda Global Gateway de la Unión Europea. Se encuentra financiado por la Unión Europea e implementado por Expertise France (Groupe AFD). Su propósito fundamental es reducir la brecha digital y fomentar la inserción laboral efectiva de la juventud salvadoreña en situación de vulnerabilidad mediante el fortalecimiento de sus capacidades tecnológicas y socioemocionales.
I.II. Necesidad de la Intervención Tecnológica
Para asegurar el éxito, la trazabilidad y la transparencia de la metodología de seguimiento (PATH) que el proyecto implementa, se ha identificado la necesidad crítica de implementar la LAMARR App. Esta plataforma debe funcionar como el núcleo tecnológico que centraliza los principales bloques de procesos de gestión, permitiendo la interacción coordinada entre los cuatro actores clave del ecosistema:
• Expertise France (EF): responsable de la supervisión estratégica, autorizaciones y visualizaciones globales de datos.
• Operador: encargado de la gestión técnica, registro de hitos y reportes operativos.
• Centros de Formación Profesional (CFPs): ejecutores de la formación, responsables del control académico y de la gestión administrativa de campo.
• Participantes: beneficiarios directos cuyo ciclo de vida en el proyecto debe ser monitoreado respecto a su participación en las actividades.
I.III. Marcos de Gestión de la Plataforma
La solución tecnológica debe dar soporte a los dos ejes metodológicos definidos en el manual de procesos del proyecto:
• PATH (Seguimiento Específico): gestiona el flujo secuencial del participante desde el proceso de selección (perfilamiento), pasando por las etapas de activación, mentoreo, alineación y transformación, hasta alcanzar la fase de expansión. Incluye el seguimiento a la empleabilidad mediante registros de inserción en empresas y la entrega de incentivos PATH.
• SERA EF (Seguimiento Transversal): estructura de monitoreo que asegura la satisfacción de la calidad, el seguimiento cuantitativo a los procesos, el control de registros y deserciones, y la medición de los indicadores del Marco Lógico para el donante.
I.IV. Gestión Operativa y Financiera
La plataforma debe automatizar procesos administrativos complejos, tales como los listados de asistencia y el registro de viáticos diarios, la gestión de solicitudes de viáticos diferenciados y el control financiero, que incluye la visualización de desembolsos y las liquidaciones correspondientes entre CFPs, Operadores y Expertise France. Toda transacción financiera deberá quedar registrada con trazabilidad completa, soporte documental digitalizado y mecanismos de conciliación automatizados.
Required profile
VII. Perfil del proveedor
• Naturaleza jurídica: empresa o consorcio legalmente constituido, con experiencia mínima de cinco (5) años en desarrollo de software y plataformas de gestión integral.
• Conocimientos técnicos: conocimientos sólidos en seguridad de la información, protección de datos personales y arquitecturas en la nube de AWS.
• Experiencia preferente: experiencia demostrable en proyectos de cooperación internacional o programas sociales (preferible).
• Cumplimiento legal: estar al día con sus obligaciones tributarias y de seguridad social en su país de origen, y declarar la ausencia de conflicto de interés con Expertise France o el donante.
• Capacidad operativa: contar con capacidad operativa para atender el proyecto en horario laboral salvadoreño (UTC-6) durante toda la vigencia del contrato.
VIII. Duración del contrato
Se estima una duración de diez (10) meses. Sin embargo, se prevé que la aplicación sea diseñada en un plazo aproximado de cuatro (4) meses, seguido de seis (6) meses de acompañamiento para su implementación y uso. Este período inicial se contará a partir de la firma del contrato y podrá ser renovado o ampliado, sujeto al desempeño del proveedor, a la disponibilidad presupuestaria y a las necesidades del proyecto. La fecha estimada de inicio será comunicada en el documento de notificación de adjudicación
IX. Criterios de evaluación
La evaluación de las ofertas se realizará bajo el principio de mejor relación calidad-precio, conforme a los siguientes ponderadores:
• Propuesta Técnica (60 %): calidad de la arquitectura propuesta, comprensión del PATH y SERA EF, y metodología de desarrollo.
• Experiencia y Perfil del Equipo (20 %): certificaciones emitidas por Scrum Alliance en Product Owner, Scrum Master y Scrum Developer, así como certificaciones en Arquitectura de Software y Cloud AWS.
• Propuesta Económica y Garantías (20 %): eficiencia de costos, plan de mantenimiento y solidez de las garantías ofrecidas.
IX.I. Propuesta Técnica (60 %)
Esta sección representa el núcleo de la evaluación y debe demostrar cómo la solución tecnológica dará soporte integral a los procesos de gestión de la LAMARR App. Los criterios de puntuación se desglosan de la siguiente manera:
IX.I.I. Arquitectura y Estándares de Desarrollo (20 %)
• Diseño de microservicios y escalabilidad: se evaluará la propuesta de arquitectura en función de su escalabilidad, modularidad, mantenibilidad y capacidad de evolución.
• Estrategia Cloud-Native en AWS: la propuesta debe detallar el uso de contenedores Docker y servicios de AWS para garantizar alta disponibilidad y resiliencia del sistema.
• Enfoque Mobile-First y UX/UI: calidad del diseño para asegurar que los procesos (p. ej. registro de asistencia y viáticos) sean funcionales y fluidos desde dispositivos móviles en campo y simultáneamente cómodos desde computadora de escritorio.
• Seguridad y gestión de roles: robustez del sistema de autenticación para los cuatro niveles de acceso (EF, Operador, CFPs y Participantes) y mecanismos de protección de datos personales.
IX.I.II. Comprensión y Digitalización del PATH – Seguimiento Específico (20 %)
El proveedor debe demostrar cómo traducirá a código el flujo secuencial del participante:
• Módulo de selección: digitalización del proceso de selección y perfilamiento inicial.
• Ciclo de formación: seguimiento técnico a las etapas de Activación, Mentoreo, Alineación y Transformación.
• Gestión de incentivos y expansión: lógica de negocio para la asignación de Incentivos PATH y el registro en la fase de Expansión.
• Vínculo con la empleabilidad: funcionalidades para el registro de empresas y el seguimiento de la inserción laboral o las deserciones.
IX.I.III. Seguimiento Transversal y Control Operativo – SERA EF (15 %)
Se evaluará la capacidad de la plataforma para consolidar datos de monitoreo y evaluación:
• Indicadores del proyecto: automatización de reportes que alimenten los indicadores del donante (Unión Europea).
• Calidad y procesos: herramientas para medir la satisfacción de la calidad y el seguimiento cuantitativo de los procesos.
• Control de asistencias y viáticos: sistema de registros diarios, cobro semanal y generación de respaldos administrativos para desembolsos.
• Gestión de expedientes: implementación del expediente en línea de calificaciones y reportes de desempeño académico.
IX.I.IV. Metodología y Visibilidad del Trabajo (5 %)
• Ciclo de vida ágil (Scrum): planificación de Sprints y entregas bi-semanales de código funcional, con corrección continua de bugs. Se espera que, de manera paralela al siguiente sprint, se solventen los bugs del sprint anterior, siendo entregados y aceptados por el cliente sin afectar la planificación del sprint en curso.
• Colaboración en GitHub: adopción estricta del flujo de trabajo en el repositorio de EF, con visibilidad diaria mediante Pull Requests y cumplimiento de estándares de código.
IX.II. Experiencia y Perfil del Equipo (20 %)
Se requiere un equipo multidisciplinario altamente calificado que garantice la calidad técnica y la agilidad en la entrega de la plataforma. Los perfiles mínimos requeridos son:
• Líder de Proyecto / Product Owner: profesional con certificación vigente de Scrum Alliance (CSPO). Será el responsable de traducir la visión estratégica del Proyecto LAMARR en historias de usuario técnicas y priorizar el Backlog de la aplicación.
• Facilitador de Procesos / Scrum Master: profesional certificado como Certified ScrumMaster (CSM) por Scrum Alliance, encargado de asegurar la agilidad del equipo, remover impedimentos técnicos y garantizar el cumplimiento del cronograma.
• Equipo de Desarrollo Senior: ingenieros certificados como Certified Scrum Developer (CSD) o equivalentes, con experiencia comprobada en el desarrollo de plataformas de gestión masiva de datos y seguimiento de expedientes en línea.
• Arquitecto de Software y Cloud: especialista con certificaciones avanzadas en Arquitectura de Software y AWS (Amazon Web Services), responsable de configurar la infraestructura en la nube que soporte el flujo de autorizaciones y visualizaciones globales de la plataforma.
• Experiencia institucional: el proveedor deberá acreditar experiencia previa en el desarrollo de sistemas de monitoreo y evaluación (M&E) para organismos internacionales o proyectos de cooperación similares al financiado por la Unión Europea.
IX.III. Propuesta Económica y Garantías (20 %)
El importe total máximo disponible en el marco de esta convocatoria es de USD 42,000.00 (cuarenta y dos mil dólares de los Estados Unidos de América, cantidad exenta de IVA, cuando aplique). El proveedor deberá presentar una oferta económica detallada, coherente con el alcance técnico, desglosando los costos de desarrollo, implementación y mantenimiento recurrente. Asimismo, deberá aceptar y detallar los siguientes mecanismos de cumplimiento:
IX.III.I. Garantía de Funcionamiento y Soporte
• Garantía técnica: el proveedor otorgará una garantía de funcionamiento óptimo de la LAMARR App por un período mínimo de tres (3) meses tras la recepción definitiva, cubriendo la corrección de errores (bugs), fallos de seguridad o inconsistencias en los flujos del PATH o SERA EF, sin costo adicional para Expertise France.
• Plan de mantenimiento: se deberá incluir un esquema de soporte post-implementación que garantice la disponibilidad del sistema y la actualización ante nuevas versiones de sistemas operativos o navegadores.
IX.III.II. Cláusulas de Cumplimiento y Compensación por Retrasos
Para garantizar la ejecución dentro de los tiempos previstos en el cronograma aprobado, se aplicarán las siguientes medidas:
• Retrasos: el proveedor deberá cumplir con el cronograma acordado. En caso de retrasos atribuibles al proveedor, se podrán aplicar penalizaciones conforme a lo establecido en el contrato, considerando hitos de entrega y no actividades individuales.
• Compensación en horas de desarrollo: alternativamente, y por mutuo acuerdo, el proveedor podrá compensar los retrasos mediante la asignación de horas de desarrollo adicionales destinadas a nuevas funcionalidades, mejoras de interfaz o ajustes en módulos no contemplados originalmente.
IX.IV. Tabla de Baremo y Asignación de Puntajes
La siguiente tabla detalla la distribución de los puntajes por criterio y sub-criterio. Cada sub-criterio será calificado por el comité evaluador aplicando una escala cualitativa que se traduce a un porcentaje del puntaje máximo asignado. La sumatoria de los tres bloques (A + B + C) totaliza 100 puntos.
|
Criterio |
Sub-criterio |
Puntaje máx. |
Descripción / evidencia requerida |
|
A. PROPUESTA TÉCNICA – 60 puntos |
|||
|
A.1 Arquitectura y estándares (20) |
Diseño de microservicios y escalabilidad |
6 |
Diagrama de arquitectura, justificación de patrones, estrategia de escalabilidad horizontal/vertical. |
|
A.1 Arquitectura y estándares (20) |
Estrategia Cloud-Native en AWS (Docker, servicios gestionados) |
6 |
Servicios AWS propuestos, contenedorización, alta disponibilidad y resiliencia. |
|
A.1 Arquitectura y estándares (20) |
Enfoque Mobile-First y UX/UI |
4 |
Wireframes / prototipos, principios de accesibilidad (WCAG 2.1 AA). |
|
A.1 Arquitectura y estándares (20) |
Seguridad, RBAC y protección de datos personales |
4 |
Estrategia de autenticación, RBAC, cifrado en tránsito/reposo, gestión de secretos. |
|
A.2 PATH (20) |
Digitalización del proceso de selección |
5 |
Mapa de flujo del proceso de selección, integraciones (validación biométrica). |
|
A.2 PATH (20) |
Ciclo de formación (Activación → Transformación) |
5 |
Definición de estados, flujos de aprobación, manejo de excepciones. |
|
A.2 PATH (20) |
Incentivos y fase de Expansión |
5 |
Reglas de negocio, motor configurable de elegibilidad. |
|
A.2 PATH (20) |
Vínculo con empleabilidad e inserción laboral |
5 |
Mecanismos de seguimiento longitudinal y formularios IC04. |
|
A.3 SERA EF (15) |
Indicadores de Marco Lógico automatizados |
5 |
Catálogo de indicadores, fórmulas y reportes automáticos. |
|
A.3 SERA EF (15) |
Calidad de procesos y satisfacción |
3 |
Encuestas, métricas de calidad, dashboards. |
|
A.3 SERA EF (15) |
Control de asistencias y viáticos |
4 |
Reglas de cálculo, anti-duplicidad, conciliación. |
|
A.3 SERA EF (15) |
Expediente académico y reportes |
3 |
Modelo de datos del expediente, reportes exportables. |
|
A.4 Metodología (5) |
Plan de Sprints y demos |
3 |
Cronograma con sprints, ceremonias y entregables. |
|
A.4 Metodología (5) |
Flujo Git, PRs y trazabilidad |
2 |
Estrategia GitFlow, definición de DoD/DoR. |
|
B. EXPERIENCIA Y PERFIL DEL EQUIPO – 20 puntos |
|||
|
B.1 Certificaciones del equipo |
Product Owner CSPO vigente |
3 |
Copia de certificación vigente. |
|
B.1 Certificaciones del equipo |
Scrum Master CSM vigente |
3 |
Copia de certificación vigente. |
|
B.1 Certificaciones del equipo |
Scrum Developer (CSD) o equivalente |
3 |
Copia de certificación vigente. |
|
B.1 Certificaciones del equipo |
Arquitecto de Software |
2 |
Certificación reconocida (TOGAF, IASA o equivalente). |
|
B.1 Certificaciones del equipo |
AWS (Solutions Architect Associate o superior) |
3 |
Certificación AWS vigente. |
|
B.2 Experiencia institucional |
Proyectos similares (mínimo 3) en cooperación / sector público |
4 |
Cartas de referencia, contratos o constancias. |
|
B.2 Experiencia institucional |
Experiencia en M&E o sistemas de Marco Lógico |
2 |
Casos de uso documentados. |
|
C. PROPUESTA ECONÓMICA Y GARANTÍAS – 20 puntos |
|||
|
C.1 Oferta económica |
Razonabilidad y desglose de costos |
8 |
Aplicación de la fórmula: P = 8 × (Pmin / Po), donde Pmin es la oferta válida más baja y Po la oferta evaluada. |
|
C.1 Oferta económica |
Coherencia con el alcance técnico |
4 |
Trazabilidad entre alcance, esfuerzo y costo. |
|
C.2 Garantías |
Garantía técnica (≥ 3 meses) |
3 |
Mecanismo y cobertura de la garantía. |
|
C.2 Garantías |
Plan de mantenimiento post-implementación |
3 |
SLA, modalidades, costos por nivel de soporte. |
|
C.2 Garantías |
Cláusulas de cumplimiento y compensación |
2 |
Mecanismo de penalización y compensación en horas. |
|
TOTAL |
100 |
||
IX.IV.I. Escala cualitativa de calificación
Para cada sub-criterio cualitativo, el comité evaluador asignará uno de los siguientes niveles, multiplicando el porcentaje correspondiente por el puntaje máximo del sub-criterio:
|
Calificación |
% asignado al sub-criterio |
Descripción |
|
Excelente |
100 % |
Cumple plenamente, supera lo solicitado y aporta valor adicional verificable. |
|
Muy bueno |
85 % |
Cumple plenamente con el requerimiento solicitado. |
|
Aceptable |
65 % |
Cumple con lo solicitado, con omisiones menores que no afectan el alcance. |
|
Insuficiente |
35 % |
Cumple parcialmente; presenta omisiones relevantes que requerirán negociación. |
|
No cumple |
0 % |
No aborda el sub-criterio o el contenido es manifiestamente inadecuado. |
IX.IV.II. Reglas de evaluación
· Cada miembro del comité evaluador completará el baremo de manera independiente; el puntaje final por subcriterio corresponderá al promedio aritmético de las calificaciones individuales.
· Para que una propuesta sea considerada elegible, deberá obtener un puntaje técnico (bloque A) de al menos 42 puntos sobre 60, equivalente al 70% del componente técnico.
· La propuesta económica será evaluada únicamente para los oferentes que superen el umbral técnico mínimo.
• Para la oferta económica se aplicará la fórmula: P = 12 × (Pmin / Po), donde Pmin es la oferta válida más baja y Po la oferta evaluada (8 puntos para razonabilidad + 4 puntos para coherencia).
· La adjudicación recaerá sobre el oferente que obtenga el mayor puntaje total acumulado, siempre que la oferta sea financieramente viable y se encuentre dentro del importe máximo disponible.
· Es requisito indispensable para la presentación de ofertas que los oferentes remitan una carta de expresión de interés, conforme al formato adjunto a los presentes términos de referencia.
· La carta de expresión de interés deberá enviarse exclusivamente por correo electrónico a la dirección sera.efslv@gmail.com a más tardar el 28 de mayo de 2026.
· Una vez recibidas las comunicaciones, el viernes 29 de mayo de 2026 se enviarán los detalles de la reunión informativa, orientada a aclarar dudas y proporcionar insumos adicionales antes de la presentación de ofertas.
· La reunión informativa con socios se llevará a cabo el lunes 1 de junio de 2026 a las 9:00 a.m. en las oficinas de Expertise France en El Salvador.
· Será requisito indispensable haber enviado la carta de expresión de interés para poder asistir a la reunión informativa.
IX.V. Negociación entre las partes
Una vez recibidas y evaluadas las ofertas, y previo a la adjudicación definitiva, Expertise France se reserva la facultad de iniciar un proceso de negociación con uno o más oferentes, con el propósito de precisar el alcance, optimizar la propuesta técnico-económica y garantizar la mejor relación calidad-precio. Este proceso se regirá por los siguientes principios y reglas:
• Carácter facultativo: la negociación es una facultad del contratante; ningún oferente podrá exigirla como un derecho. La ausencia de negociación no implica la descalificación de ninguna oferta.
• Oferentes invitados: podrán ser invitados a negociar el oferente mejor evaluado y/o aquellos cuyo puntaje técnico se ubique dentro de un margen del 10 % respecto del oferente líder, a criterio del comité evaluador.
• Objeto de la negociación: podrá versar sobre el detalle del alcance funcional y técnico, el cronograma, los entregables, los niveles de servicio (SLA), la composición y dedicación del equipo, los mecanismos de garantía y/o el precio, sin alterar los requisitos mínimos y excluyentes del TDR.
• Mantenimiento de condiciones esenciales: la negociación no podrá alterar los criterios sustanciales de evaluación ya valorados, ni implicar discriminación entre oferentes. En ningún caso el resultado de la negociación podrá superar el importe máximo disponible (USD 42,000.00) ni reducir el alcance esencial del proyecto.
• Modalidad y registro: la negociación se podrá realizar de forma virtual o presencial. Cada sesión será registrada formalmente mediante acta o minuta firmada por ambas partes, donde se consignen los acuerdos alcanzados. Toda comunicación deberá realizarse por escrito a través de los canales oficiales establecidos por Expertise France.
• Resultado: los acuerdos alcanzados serán incorporados como anexo al contrato y formarán parte integrante del mismo. En caso de no llegarse a un acuerdo con el primer oferente invitado, Expertise France podrá iniciar negociaciones con el siguiente oferente mejor evaluado.
• Plazo: la negociación deberá completarse en un plazo máximo de cinco (5) días hábiles contados a partir de la convocatoria al oferente, prorrogable por una única vez por causas debidamente justificadas.
• Confidencialidad: toda la información intercambiada durante la negociación tendrá carácter confidencial y no podrá ser divulgada a terceros sin autorización expresa del contratante.
IX.VI. Niveles de Servicio (SLA)
El proveedor deberá incluir dentro de su propuesta un esquema de niveles de servicio (SLA) que garantice la continuidad operativa y el adecuado soporte de la plataforma. Como mínimo, deberá contemplar:
• Tiempos de respuesta ante incidentes, clasificados por nivel de criticidad (alta, media, baja).
• Tiempos de resolución estimados para cada tipo de incidente.
• Disponibilidad esperada del sistema (uptime mínimo del 99 % en horario operativo).
• Mecanismos de soporte técnico (canales, horarios de atención y procedimientos de escalamiento).
• Procedimientos de gestión de incidencias y seguimiento.
El cumplimiento de estos niveles de servicio será considerado dentro de los mecanismos de evaluación, seguimiento y, eventualmente, penalización del contrato.
Additional information
X. Consultas y aclaraciones a los TDR
Los proveedores interesados podrán canalizar consultas escritas hasta el 10 de junio de 2026 al correo electrónico sera.efslv@gmail.com. No obstante, será imprescindible, para que su oferta sea admitida en el proceso de evaluación, que cumplan con las condiciones establecidas en el apartado “IX.IV.II. Reglas de evaluación”.
XI. Lineamientos tecnológicos y estándares de desarrollo
Para garantizar la transparencia, la propiedad intelectual y la calidad técnica de la LAMARR App, el proveedor deberá cumplir con los siguientes lineamientos:
XI.I. Gestión del Código Fuente y Visibilidad
• Repositorio obligatorio: todo el desarrollo deberá realizarse en la organización de GitHub de Expertise France (EF). EF mantendrá la propiedad y la administración total del repositorio desde el inicio del contrato.
• Flujo de trabajo: el proveedor deberá garantizar la trazabilidad del desarrollo mediante el uso de repositorios de código y buenas prácticas de control de versiones, incluyendo revisiones de código y entregas incrementales.
• Buenas prácticas: se establecerá, de mutuo acuerdo, un flujo de trabajo basado en GitFlow o equivalente, siendo obligatorio el uso de Pull Requests (PR) para la revisión de código.
• Gestión de accesos: EF mantendrá los privilegios de Administrador. El proveedor recibirá únicamente los permisos de «Developer» necesarios para la ejecución de sus tareas, sin acceso a configuraciones críticas de seguridad o administración de la organización.
XI.II. Stack Tecnológico y Arquitectura
• Backend: el proveedor deberá proponer una arquitectura tecnológica escalable, modular y basada en buenas prácticas de la industria, que permita el crecimiento progresivo de la solución. Se valorará positivamente el uso de arquitecturas desacopladas y orientadas a servicios.
• Frontend y despliegue híbrido: la solución deberá permitir acceso web y móvil. El proveedor propondrá las tecnologías más adecuadas para garantizar una experiencia óptima de usuario, rendimiento y mantenibilidad.
• Segregación de entornos (Backoffice vs. App): el desarrollo se dividirá en dos ecosistemas independientes pero comunicados:
◦ Aplicación móvil (tecnología propuesta por el proveedor): enfocada en el usuario final y la movilidad.
◦ Portal administrativo (web): dedicado exclusivamente a la gestión operativa de la plataforma. Incluirá flujos de aprobación y auditoría; páginas administrativas y gestión de roles/permisos; monitoreo y seguimiento de casos en tiempo real; módulos de reportería avanzada y dashboards de KPIs; gestión de contenidos (CMS) y configuración de parámetros globales; logs de sistema y herramientas de soporte técnico.
El proveedor deberá identificar los flujos que requieran disponibilidad en entornos web y móvil. En caso de requerirse implementación en múltiples entornos, esto deberá estar contemplado dentro de la propuesta técnica y económica.
• Base de datos: se empleará PostgreSQL como sistema de gestión de base de datos relacional, asegurando la integridad de la información del PATH y SERA EF.
XI.III. Infraestructura y Despliegue
• Entorno cloud: la plataforma será desplegada exclusivamente en la infraestructura de AWS (Amazon Web Services) propiedad de EF.
• Estándares Cloud-Native: el código fuente y la arquitectura deben seguir estándares de «nube nativa» para asegurar escalabilidad y resiliencia.
• Contenedores: se espera el uso de Docker para la contenedorización de las aplicaciones, facilitando la portabilidad y la consistencia entre los entornos de desarrollo, pruebas y producción.
• Administración de la nube: la solución deberá ser desplegada en la infraestructura cloud definida por la entidad contratante. El proveedor deberá coordinar el uso de accesos y recursos bajo los lineamientos de seguridad establecidos.
XI.IV. Calidad del Código y Base de Datos
• Estrategia de pruebas (unitarias e integración): no se exige una cobertura del 100 %, priorizando la calidad sobre la cantidad. Sin embargo, los tests unitarios y de integración deben cubrir obligatoriamente los casos principales, básicos y los escenarios especiales (edge cases).
• Nomenclatura de tests: cada prueba debe poseer un nombre semántico y descriptivo que identifique claramente el escenario técnico o funcional verificado.
• Facultad de revisión: EF se reserva el derecho de solicitar la creación de tests unitarios adicionales para componentes específicos antes de dar por recibido un sprint, si considera que la lógica crítica no está debidamente respaldada.
• Normalización y estándares de BD: la base de datos debe ser relacional (PostgreSQL) y cumplir estrictamente con las reglas de normalización para garantizar la integridad y la eficiencia de los datos.
• Convención de nomenclatura: todos los nombres de tablas, columnas, variables, clases y métodos en el código fuente deben seguir un único idioma (inglés o español), a definir en la reunión de arranque.
• Código semántico y limpio: se deberá evitar el uso de nombres genéricos o temporales (p. ej. temp, variable1, aux). Los nombres deben ser descriptivos de su función.
• Reducción de boilerplate: el proveedor debe evitar el código repetitivo, favoreciendo la modularidad y el uso eficiente de los frameworks seleccionados.
• Refactorización: la calidad del código será validada durante el proceso de desarrollo. Los ajustes menores podrán ser solicitados como parte del aseguramiento de calidad; los cambios estructurales se gestionarán como parte del control de cambios del proyecto.
XI.V. Uso de Inteligencia Artificial y Responsabilidad Técnica
• Uso de IA: no se prohíbe el uso de herramientas de IA, pero no se aceptará código generado al 100 % por estas herramientas sin supervisión humana.
• Responsabilidad del commit: cada desarrollador es 100 % responsable de las líneas de código que suba al repositorio. EF realizará entrevistas técnicas aleatorias sobre la lógica implementada; si el desarrollador no puede explicar su propio código, el avance no será aceptado.
• Autenticidad del equipo: esta medida busca garantizar que el equipo ofertado es quien efectivamente ejecuta el trabajo, evitando suplantaciones o el uso de un único recurso operando bajo múltiples perfiles.
XI.VI. Ciclo de Aceptación, QA y Desembolsos
• Certificación de QA: EF podrá designar un especialista de QA externo. La aceptación de cada sprint y la liberación de los fondos correspondientes estarán condicionadas a que el QA certifique que la entrega está libre de errores críticos y cumple con los requerimientos.
• Documentación de API y endpoints: el proveedor tiene la obligación de mantener y actualizar permanentemente una colección de endpoints (p. ej. en Postman). Esta colección debe incluir los requests y payloads necesarios para replicar todos los escenarios validados en el backend.
• Facilitación para QA: dicha colección es un entregable vivo que debe permitir al equipo de QA de EF (o a especialistas externos) validar los casos de uso de forma ágil, sin depender exclusivamente de la interfaz técnica del proveedor.
• Entorno de testing obligatorio: para las demostraciones de los sprints (Demos), las funcionalidades deben estar desplegadas en un ambiente de testing en la nube. No se aceptarán revisiones en computadoras locales de los desarrolladores ni capturas de pantalla de GitHub.
• Criterios de éxito (Happy Path): aunque no se espera perfección absoluta en etapas tempranas, el camino principal o Happy Path de cada funcionalidad debe ser 100 % operativo.
• Confiabilidad de componentes: los controles y componentes de la interfaz deben modificarse lo mínimo necesario para asegurar la estabilidad y la confiabilidad del sistema.
XI.VII. Gestión del Talento y Programa de Mentoría
• Permanencia del equipo: los desarrolladores presentados en la oferta deben ser quienes trabajen efectivamente en el proyecto. Cualquier cambio por vacaciones o salida de la empresa debe ser comunicado y su reemplazo aprobado previamente por EF.
• Sustitución de personal: EF se reserva el derecho de solicitar el cambio de cualquier desarrollador cuyo desempeño o comprensión del negocio no alcance las expectativas del proyecto.
• Integración de beneficiarios (juniors): como entidad generadora de oportunidades, EF incorporará entre tres (3) y cinco (5) desarrolladores Junior (beneficiarios del proyecto), quienes serán remunerados directamente por EF.
• Responsabilidad del proveedor: el proveedor deberá actuar como mentor, asignando tareas acordes al nivel de los juniors y supervisando estrictamente sus actividades para no comprometer la calidad de la LAMARR App.
XI.VIII. Cuadro de Buenas y Malas Prácticas (Ejemplos)
|
Lo que SE DEBE hacer (Buenas prácticas) |
Lo que NO SE DEBE hacer (Prohibido) |
|
Comentar funciones complejas y documentar la API. |
Subir credenciales o llaves API al repositorio de GitHub. |
|
Realizar Pull Requests (PR) pequeños y frecuentes. |
Hacer «mega-commits» de cientos de líneas de código. |
|
Escribir pruebas unitarias para la lógica de negocio. |
Ignorar errores de compilación o advertencias del linter. |
|
Seguir los principios SOLID de diseño de software. |
Duplicar lógica de negocio en diferentes módulos (copy-paste). |
|
Mantener la base de datos en Tercera Forma Normal (3FN). |
Usar variables globales que afecten el estado de la app. |
XII. Cronograma del proceso de licitación
El proceso de contratación se regirá por el siguiente cronograma referencial, a partir de la publicación de los TDR:
|
Fase |
Actividad |
Fecha |
|
1 |
Publicación de los TDR |
19 de mayo de 2026 |
|
2 |
Presentación de carta de expresión de interés |
28 de mayo de 2026 |
|
3 |
Envío de detalles de la reunión informativa |
29 de mayo de 2026 |
|
4 |
Reunión informativa con potenciales ofertantes |
1 de junio de 2026, 9:00 a.m. |
|
5 |
Período de consultas y aclaraciones por escrito |
Hasta el 10 de junio de 2026 |
|
7 |
Fecha límite de recepción de propuestas por proveedores |
12 de junio de 2026 |
|
8 |
Evaluación técnica y financiera |
Posterior al cierre |
|
9 |
Negociación, cuando aplique |
Según IX.V |
|
10 |
Notificación de resultados |
Posterior a la evaluación |
XIII. Checklist de cumplimiento para proveedores
Los proveedores deberán asegurarse de que su propuesta cumple con los siguientes requisitos mínimos, entre los que es imprescindible haber presentado previamente la carta de expresión de interés. El incumplimiento de uno o más de estos requisitos podrá derivar en la descalificación de la propuesta.
Documentación general
• Carta de presentación de la empresa.
• Información legal de la empresa (constitución, representación, NIT/RUT).
• Experiencia comprobable (mínimo 5 años).
• Referencias de proyectos similares.
• Declaración de no estar inhabilitado y de ausencia de conflicto de interés.
Propuesta técnica
• Descripción de la arquitectura propuesta.
• Enfoque de desarrollo (Scrum, entregas, QA).
• Comprensión del modelo PATH y SERA EF.
• Propuesta de solución alineada a los módulos y épicas del TDR.
• Estrategia de despliegue en AWS.
• Enfoque de seguridad y gestión de accesos.
Equipo de trabajo
• Perfil del Product Owner.
• Perfil del Scrum Master.
• Perfil del equipo de desarrollo.
• Perfil del arquitecto de software / cloud.
• Certificaciones relevantes (Scrum, AWS, etc.).
Propuesta económica
• Desglose de costos (desarrollo, implementación, mantenimiento).
• Cronograma de pagos propuesto.
• Inclusión de garantía técnica.
• Plan de soporte post-implementación.
Cumplimiento técnico
• Aceptación del uso de GitHub de EF.
• Aceptación del despliegue en AWS de EF.
• Aceptación del flujo de trabajo con Pull Requests.
• Aceptación de la revisión de código y QA externo.
Otros
• Aceptación de las condiciones del TDR.
• Aceptación de la posibilidad de negociación con el contratante (sección IX.V).
• Disponibilidad del equipo durante la duración del proyecto.
• Compromiso de confidencialidad.
Selection criteria for applications
The selection process for candidates will be based on the following criteria :
- Candidate’s training/skills/experience
Deadline for application : 2026/06/12 23:55
File(s) attached : TDR - Contratacion de servicios app LAMARR 18 de mayo 2026.docx
Expertise France is the public agency for designing and implementing international technical cooperation projects. The agency operates around four key priorities :
- democratic, economic, and financial governance ;
- peace, stability, and security ;
- climate, agriculture, and sustainable development ;
- health and human development ;
In these areas, Expertise France conducts capacity-building initiatives and manages project implementation, leveraging technical expertise and acting as a project coordinator. This involves combining public sector expertise with private sector skills to drive impactful results.