Aceptar una entrega de proveedor
Hay que decidir si se acepta, y la única información disponible es que funciona en la demostración.
Ingeniería y calidad
Auditoría técnica coordinada de desarrollos para Moodle
Este sistema audita de forma coordinada las extensiones de Moodle, la configuración de la plataforma y el entorno en el que se ejecuta.
El problema
Una revisión manual o una única herramienta cubre solo una parte de un desarrollo para Moodle. La seguridad, las API, la interfaz, las pruebas, la compatibilidad, la configuración y el servidor exigen comprobaciones distintas que deben terminar en un informe coherente.
Revisar una extensión exige relacionar código, datos y operación.
Una auditoría limitada al estilo puede omitir permisos, consultas costosas, tareas, eventos, privacidad o rutas de actualización. La revisión examina el código, la configuración, el despliegue y la operación de la extensión, y prioriza los hallazgos según su impacto y el esfuerzo necesario para corregirlos.
Decisión principal
Distinguir defecto, deuda y elección arquitectónica.
No todo desacuerdo merece la misma prioridad. El informe separa incumplimientos verificables, riesgos probables y decisiones que necesitan contexto. Esa clasificación permite al equipo actuar sin convertir la auditoría en una lista indiscriminada.
Criterios de diseño
- 01
Combino motores deterministas, reglas específicas de Moodle y revisión especializada, conservando por separado las evidencias de cada fuente.
- 02
Normalizo cada hallazgo para conservar su origen, su severidad, la regla aplicada, la ubicación y la propuesta de corrección.
- 03
La auditoría cubre el código, la configuración y el entorno de ejecución, y termina en un informe que puede revisarse.
Límites del producto
La auditoría distingue los hechos de las hipótesis.
Cuando faltan datos de carga, producción o integración, el hallazgo se formula como hipótesis y se acompaña de una prueba. Esta disciplina protege la credibilidad del informe y evita recomendaciones desproporcionadas.
Capacidades del sistema
- 01Seguridad y calidad de código
- 02API internas, servicios web e interfaz
- 03Pruebas, cobertura funcional y duplicación
- 04Configuración y endurecimiento del servidor
Criterio de validación
Cada hallazgo debe poder confirmarse y volver a probarse.
La documentación incluye la ubicación, la condición, el efecto, la severidad, la corrección propuesta y el método de validación. Tras el cambio, el mismo control debe confirmar que la condición ya no se reproduce, y las pruebas previstas no deben detectar regresiones.
Evidencia descrita para la auditoría técnica coordinada de desarrollos para Moodle
- Orquestador de auditoría por fases
- Motores propios para código y servidor
- Catálogo versionado de reglas y hallazgos normalizados
- CLI, servidores MCP, visor de revisión e informes JSON y DOCX
Preguntas abiertas
Decisiones pendientes en la auditoría técnica coordinada de desarrollos para Moodle.
Antes de extender la auditoría, hay que contrastar la severidad, el coste de cada comprobación, la tasa de falsos positivos y la compatibilidad con distintas versiones.
- Calibración de severidades por contexto
- Coste de cada comprobación
- Tasa de falsos positivos
- Compatibilidad por versión de Moodle
- Política de aceptación de riesgos
- Integración progresiva en CI/CD
Contextos en los que encaja
Las situaciones en las que he tenido que revisar código ajeno
Nunca por curiosidad: siempre hay una decisión detrás esperando.
Heredar una plataforma sin documentación
Alguien la construyó, ya no está, y hay que decidir si se mantiene o se rehace.
Antes de una compra
Se valora adquirir un desarrollo y nadie ha mirado lo que hay dentro.
Después de un incidente de seguridad
Y la pregunta no es solo qué pasó, sino qué más hay ahí con el mismo problema.
Decisiones de arquitectura
Las decisiones que lleva dentro
Una revisión vale por lo que se puede comprobar después, no por lo gruesa que sea.
- 01
Separar evidencia y valoración
Cada comprobación determinista conserva su regla y su resultado. La ausencia de una comprobación de permisos es observable; decidir si ese punto debía comprobar el permiso y valorar su gravedad exige contrastar el flujo y el contexto. Los riesgos y las decisiones contextuales se registran aparte con sus criterios, hipótesis y prueba de confirmación.
- 02
Severidad por consecuencia
Lo que expone datos o tumba el servicio va primero. Mezclarlo con lo que molesta al leer es la forma más rápida de que no se arregle nada.
- 03
Intentar refutarme antes de escribir
Un hallazgo plausible que resulta falso destruye la credibilidad de los otros veinte. Antes de publicarlo, intento demostrar que me equivoco.
A escala
Qué cambia con el tamaño de lo revisado
- Una extensión
Si es pequeña y está acotada, puede leerse completa. Las comprobaciones automatizadas siguen aportando un criterio homogéneo; su peso depende del tamaño, la complejidad y el número de componentes.
- Una plataforma con decenas de desarrollos
La automatización puede compensar: las comprobaciones repetibles filtran y el criterio se reserva para lo que queda.
- Varias plataformas
El catálogo de reglas versionado deja de ser comodidad: sin él, cada revisión mide con un listón distinto.
Capacidades puestas en práctica
Una revisión técnica que termina en correcciones comprobables
Este proyecto muestra cómo convierto los criterios de revisión de Moodle en comprobaciones reproducibles y en un informe cuyos hallazgos el equipo puede corregir y volver a validar.
- 01Liderazgo técnico
- 02Calidad automatizada
- 03CI/CD y seguridad
- 04Criterio técnico compartido
Contexto profesional