Moodle · Contratación
La mayor parte de los pliegos que he leído describen lo que la plataforma debe tener y casi ninguno explica cómo comprobar que lo tiene. Esa diferencia determina cuánto sirve el contrato durante la aceptación y el funcionamiento diario. Para reducir disputas, redacto cada requisito con tres elementos: qué exijo, qué evidencia debe entregar el proveedor y qué criterio aplico para darlo por cumplido. No considero exigible «plataforma escalable» sin más precisión. Para definir una prueba de carga comparable, fijo el guion y los datos, la mezcla de acciones, la rampa y la duración, el punto de medición, el umbral de errores, el percentil de cada recorrido y las condiciones del entorno. Aplico el mismo criterio a la seguridad, la accesibilidad, la continuidad y, sobre todo, a la salida del proveedor.
Escribo requisitos comprobables sobre volumetría, percentiles de respuesta, seguridad, accesibilidad, continuidad y plan de salida. Asocio cada requisito con un criterio de aceptación, una evidencia y una responsabilidad, e incluyo un entorno de pruebas y objetivos de recuperación medibles.
Mi trayectoriaCuatro situaciones en las que he visto el coste de un pliego que no obligaba al proveedor a cumplir nada concreto.
El pliego decía «escalable» y el proveedor entregó una plataforma compatible con esa descripción. Sin cifras ni condiciones de prueba acordadas, me cuesta mucho más acreditar que incumple el rendimiento exigido y cerrar la aceptación sin disputas.
He recibido código que funciona, pero solo lo entiende quien lo escribió: no tiene documentación ni pruebas. Al cambiar el equipo responsable, he tenido que rehacerlo.
He encontrado copias de seguridad sin un tiempo de recuperación definido. Descubrí durante el incidente que el plazo real era de días.
He recibido los datos, pero no la arquitectura, los procedimientos ni las decisiones. La continuidad me ha obligado a seguir con el mismo equipo.
Aplico siempre la misma estructura a cualquier apartado del pliego.
Formulo el requisito con una cifra, un plazo o un comportamiento observable. Si no puedo comprobarlo con uno de esos tres elementos, lo considero una declaración de intenciones.
Defino en el pliego qué evidencia debe entregar el proveedor: un informe, una prueba ejecutada, un documento o una demostración en un entorno de pruebas. No la negocio al final.
Fijo el umbral concreto que separa el cumplimiento del incumplimiento. Sin él, discutimos la aceptación a partir de opiniones enfrentadas.
Identifico los requisitos que dependen de la organización: dar acceso, aportar datos y decidir a tiempo. Reparto por escrito la responsabilidad de cada parte para evitar conflictos sobre el alcance y la aceptación.
Plantilla orientativa: hay que completar los campos entre corchetes y validar cada umbral antes de incorporarla a un pliego.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Volumetría y concurrencia declaradas por la organización | Número de personas matriculadas, cifra de sesiones simultáneas en el pico de actividad y calendario de convocatorias | La documentación contractual incluye el número de personas matriculadas, la concurrencia simultánea por recorrido, el calendario de picos, el crecimiento previsto y el volumen de almacenamiento. Cada cifra especifica su unidad, periodo y fuente. |
| Tiempos máximos de resolución por criticidad | Clasificación de incidencias y plazo máximo para cada nivel, contado desde el registro | P1: primera respuesta en ≤ [X] minutos y restauración del funcionamiento o resolución de la incidencia en ≤ [Y] horas desde el registro; el contrato define cómo se computan los plazos, qué pausas se admiten y cuándo se cierra la incidencia |
| Disponibilidad comprometida y cómo se mide | Porcentaje, ventana de medición y qué cuenta como caída | Disponibilidad mensual ≥ [X] %; el contrato define la fórmula, la fuente de medición, qué paradas planificadas se excluyen y cómo se tratan las dependencias externas |
| Integridad académica y detección de coincidencias | Cómo se integra en las actividades con entrega, qué ocurre con los documentos analizados y quién los conserva | El proveedor declara destino, finalidad, conservación y borrado de cada documento; todo resultado que pueda afectar a una persona exige revisión humana y un procedimiento de reclamación |
| Accesibilidad exigida y cómo se comprueba | Norma y versión, alcance y exclusiones justificadas, muestreo, revisión manual y automática, e informe con plan de corrección | Fijar el alcance según la norma aplicable. Excluir el contenido aportado por el profesorado solo cuando encaje en una exclusión legal —por ejemplo, contenido de terceros no financiado, desarrollado ni controlado por la entidad— y justificar que cumple esa condición. Declarar los incumplimientos admitidos, el plan de corrección y el criterio de aceptación. |
| Peso real de cada criterio de adjudicación | Reparto de puntos entre precio, calidad técnica, contenidos y memoria de gestión | Los criterios y subcriterios suman el 100 % de la puntuación y sus fórmulas están documentadas. Una simulación con los escenarios acordados confirma que no hay errores de cálculo que alteren el orden ni umbrales no publicados. |
| Alcance del contenido formativo, cuando se incluye en el mismo contrato | Qué contenidos se producen o actualizan, qué normas sectoriales deben cumplir y quién los valida | Comprobar que cada pieza tiene definidos el formato, la extensión, la norma aplicable, la fecha de entrega, quién la valida y los criterios de corrección. Aceptarla solo si cumple todos esos requisitos. |
| Coexistencia con otras plataformas de la institución | Qué ocurre cuando conviven varias plataformas de aprendizaje y quién unifica la identidad y los resultados | Documentar y probar de principio a fin los flujos de identidad, catálogo y resultados entre plataformas, con los perfiles y casos de error acordados |
| Concurrencia soportada | Prueba de carga que reproduzca el recorrido de un examen | La prueba reproduce el guion, los datos, la mezcla de acciones, la rampa, la duración, el punto de medición y el entorno acordados. Atiende a [X] usuarios simultáneos, mantiene los errores por debajo de [Y] % y, en cada recorrido definido, cumple un tiempo máximo de [Z] en el percentil 95. |
| Recuperación del servicio | Ensayo de restauración completa con tiempos reales | Funcionamiento restablecido dentro del plazo fijado, con acta firmada |
| Calidad del código entregado | Análisis estático, cumplimiento del estándar de la plataforma y pruebas automatizadas | Sin incidencias bloqueantes y con la cobertura de pruebas fijada para la lógica propia |
| Actualización de versión | Ensayo de actualización en entorno de pruebas con inventario de extensiones | Completar la actualización sin perder ninguna de las funciones exigidas |
| Transmitir el conocimiento | Decisiones documentadas y formación impartida al equipo interno | El equipo propio ejecuta una operación crítica sin el proveedor delante |
| Plan de salida | Procedimiento de exportación en formatos reutilizables | Ejecutar una prueba real de exportación completa mientras dure el trabajo |
Los ordeno según lo que más veces he visto faltar cuando ya era tarde.
Incluyo los usuarios activos, el pico de usuarios simultáneos, la franja horaria, el crecimiento previsto y el volumen de almacenamiento. Estos datos determinan el diseño, el precio y la comparación entre ofertas.
Defino dos criterios: el tiempo de respuesta por tipo de página, expresado en percentiles y no en medias, y una prueba de carga que reproduzca el recorrido real de un examen o una matrícula.
Tiempo máximo de parada, pérdida máxima asumible, consistencia entre la base de datos y los ficheros, y al menos un ensayo anual de restauración con acta.
Gestión de vulnerabilidades, registros de auditoría, retención y supresión de datos, y accesibilidad conforme a la norma aplicable, acreditada con un informe de revisión y no con una declaración.
Cada integración debe tener un contrato que recoja el sistema de referencia, el equipo responsable, un identificador estable, el comportamiento ante errores y la reconciliación periódica.
Identificar las licencias del núcleo, las dependencias y los componentes previos. Entregar el código fuente, la documentación y los procedimientos de construcción y despliegue. Garantizar los derechos de uso, modificación y continuidad. Establecer la titularidad de los desarrollos a medida solo cuando se haya acordado y sea jurídicamente procedente. Probar la salida con una exportación en formatos reutilizables.
Si falla una comprobación aplicable al contrato, puede quedar una obligación insuficientemente definida y aumentar el riesgo de disputa.
Identifico seis defectos que convierten un pliego largo en un pliego débil.
Evito exigir una solución concreta en lugar del comportamiento esperado: reduce la competencia y ata a la organización a una tecnología antes de saber si es la adecuada.
No doy por bueno un tiempo medio de respuesta: puede ser bueno y, aun así, ocultar una experiencia pésima para una parte de las personas. Uso percentiles para ver los tiempos que sufre la cola de la distribución.
Aceptar una declaración de conformidad sin informe de revisión ni plan de corrección deja el requisito sin efecto real.
Exijo un entorno de pruebas en el pliego. Si no se incluye, la organización no puede dar por garantizada su disponibilidad ni utilizarlo como evidencia de aceptación.
Si solo valoro el precio y la experiencia declarada, elijo a quien mejor escribe la memoria, no a quien mejor construye la plataforma.
Un procedimiento de reversibilidad escrito y nunca ejecutado no sirve. Exijo una prueba real durante la vigencia del contrato.
No atribuyo mala fe a ninguna: veo atajos razonables que dejan a la organización sin capacidad de exigir.
Detecto volumetría, integraciones y prioridades heredadas de otra organización, que no son las de la vuestra. También detecto huecos que aún nadie ha revisado.
En una lista de módulos y características solo veo descrita la solución, no sus condiciones de funcionamiento. Echo en falta todo lo que determina si la plataforma funcionará: capacidad, operación, seguridad y evolución.
He comprobado que lo que no queda definido en los documentos contractuales es más difícil de exigir y puede requerir una interpretación o una modificación que debe validar el órgano de contratación. Por eso concreto desde el pliego la continuidad, la accesibilidad y la salida.
No uso el mismo pliego para una academia que para una plataforma autonómica.
Priorizo la volumetría y el rendimiento, la continuidad, la seguridad, la privacidad y la accesibilidad según el tipo de plataforma. Fijo las responsabilidades, los derechos de uso, la entrega y un procedimiento de salida probado. Añado los procesos completos de ingeniería cuando hay desarrollo a medida o integraciones que deban mantenerse.
Incluyo la calidad del código, las pruebas, la documentación de las decisiones y el despliegue reproducible. Sin estas prácticas, solo quien desarrolló la solución podrá mantenerla.
Exijo alta disponibilidad, observabilidad incluida en la entrega, pruebas de carga y ensayos de continuidad. Vinculo las penalizaciones a criterios medibles, no a percepciones.
Incluyo el esquema de seguridad y los requisitos de accesibilidad y protección de datos que correspondan. Concreto la reversibilidad en los pliegos cuando la exige una obligación jurídica o contractual.
Referencias
Marco aplicable al sector público y, en las condiciones del artículo 2.3, a los sistemas de entidades privadas que le prestan servicios o le proveen soluciones para el ejercicio de sus competencias. Consultado el 3 de agosto de 2026.
Obligaciones de accesibilidad, declaración y revisión. Consultado el 1 de agosto de 2026.
Norma técnica de referencia para los requisitos de accesibilidad en contratación pública. Consultado el 1 de agosto de 2026.
La estructura de requisito, evidencia y criterio de aceptación es criterio propio, formado escribiendo y revisando requisitos técnicos, no una metodología oficial de contratación. Las cifras de ejemplo son ilustrativas: cada organización tiene que fijar las suyas a partir de su volumetría real. Esta página no sustituye al asesoramiento jurídico ni al del órgano de contratación, que son quienes deben validar la redacción final y la normativa aplicable a cada caso.
Blog
En el blog desarrollo requisitos de contratación con ejemplos, fuentes y criterios de aceptación adaptados a cada contexto.
Ir a blog.albertolarah.comContacto
Miro el alcance del contrato, la volumetría, si hay desarrollo a medida y las obligaciones normativas que apliquen. Con eso leo la documentación técnica y señalo qué compromisos no asume el proveedor.
hola@albertolarah.comLinkedIn ↗