NOTAS AL ORADOR:
- **Inicio formal y pausa breve.**
- Presentarte: “Soy Ernesto Serrano…”.
- Recordar: título, línea del programa y dirección del doctor JJ Merelo.
- **Gatillo:** “repositorios como sistemas complejos → transición crítica”.
NOTAS AL ORADOR:
- Conectar con Soft Computing: “los repositorios no son fábricas, son sistemas autoorganizados”.
- Aclarar que el caso eXeLearning funciona como **laboratorio experimental**.
- **Gatillo:** “estructura clara y normativa → hoja de ruta".
NOTAS AL ORADOR:
- Enumerar con los dedos si ayuda.
- Seguir el orden exacto de la normativa.
- **Gatillo:** “Estado del arte → problema → hipótesis → metodología → impacto”.
NOTAS AL ORADOR:
- Entrar en modo narrativo, tono cercano.
- REA = recursos abiertos, reutilizables, accesibles
- Explicar qué es eXeLearning y por qué es crítico en educación.
- **Gatillo:** “No es arreglar un programa → es estudiar un fenómeno”.
NOTAS AL ORADOR:
- Contar el conflicto: “transición forzosa bajo presión”.
- Enfasis: el vacío en la literatura → cómo gestionar esa transición.
- **Gatillo:** presentar eXe como “paciente”.
NOTAS AL ORADOR:
- Presentar el peso real del proyecto: “herramienta crítica en educación”.
- Citar números .
- Google Scholar: 7860 resultados
- Web of Science: 130 resultados
- Dialnet: 101 resultados
- DigiBug: 21 resultados
- **Gatillo:** “no es menor → es infraestructura educativa”.
NOTAS AL ORADOR:
- Explicar brevemente la metáfora.
- El bazar tiene ventajas (resiliencia, diversidad) pero también riesgos (fragmentación, falta de dirección)
- Referenciar brevemente la literatura sobre modelos de desarrollo OSS (Raymond, Capiluppi & Michlmayr).
- Resaltar que esta **transición no fue buscada**.
- **Gatillo:** “riesgos del bazar → caos si no se estructura”.
NOTAS AL ORADOR:
- Exponer la “tormenta perfecta”: crisis tecnológica + organizativa.
- **Gatillo:** “Aquí la ingeniería deja paso a la ciencia”.
- Marcar la motivación del caso como punto de partida, no como el fin.
NOTAS AL ORADOR:
- Dejar claro que la tesis no asume que DevOps funcione por defecto: se propone estudiarlo empíricamente.
- Conectar con la rúbrica: de la revisión del estado del conocimiento se deriva un problema bien definido.
- Presentarlo como *problema científico*, no técnico.
- **Gatillo:** “migrar un monolito mientras cambia la gobernanza”.
- Dejar claro que las hipótesis se van a poner a prueba.
NOTAS AL ORADOR:
- Exponer los 4 pilares con frases breves.
- **Gatillo:** “Teseo = identidad”, “Strangler = sustitución gradual”.
- ¿y Soft Computing dónde está exactamente?” Podemos usar tecnicas como: clustering de contribuciones, análisis de series temporales, quizá modelos predictivos ligeros sobre métricas.
- DevOps no es solo despliegue: remarcar “reducción de entropía”.
NOTAS AL ORADOR:
- Tono claro: hipótesis contrastable, no conclusión.
- **Gatillo:** “DevOps → catalizador en transiciones OSS”.
NOTAS AL ORADOR:
- Recalcar la idea clave: **el software es un subproducto**, la tesis es la metodología.
- **Gatillo:** “caso de estudio → laboratorio”.
NOTAS AL ORADOR:
- Relacionar con el esquema mnemotécnico: Diagnosticar → Implantar → Evaluar.
- O1 – Diagnosticar
- Definir y calcular un conjunto de métricas de proceso (p. ej. tiempo de ciclo, frecuencia de versiones) y de producto (p. ej. defectos, complejidad c., cobertura) del estado inicial.
- Caracterizar también la comunidad y la *developer experience* (DX) mediante datos del repositorio y cuestionarios breves.
- O2 – Proponer e implantar
- Diseñar una metodología de modernización inspirada en prácticas DevOps que especifique qué cambios de proceso se introducen y qué métricas se pretende mejorar.
- Implantar dicha metodología en el caso de estudio, incluyendo automatización parcial, pruebas y revisión colaborativa.
- O3 – Evaluar
- Analizar la evolución de las métricas de proceso, producto y DX tras la intervención, comparándolas con la línea base.
- Extraer pautas y condiciones de aplicabilidad para otros proyectos de características similares.
- **Gatillo:** “Antes / Después”.
NOTAS AL ORADOR:
- Enfatizar que el enfoque es mixto (cuantitativo + cualitativo).
- Introducción de pruebas, análisis estático y flujos de colaboración.
- IMPORTANTE: Siguiendo el rigor científico, no aplicaremos cambios masivos al sistema crítico desde el día 1.
Primero aislaremos un módulo (piloto) para validar
que nuestras métricas de control funcionan, y solo entonces escalaremos
- **Gatillo:** “datos históricos → 15 años”.
- Recordar que no hay tratamiento de datos sensibles.
NOTAS AL ORADOR:
- Frase resumen:
**Año 1 → Diagnóstico. Año 2 → Intervención. Año 3 → Validación.**
- Mostrar seguridad en la viabilidad.
NOTAS AL ORADOR:
- Ser directo: “No requiere financiación externa relevante”.
- **Gatillo:** “viabilidad total”.
NOTAS AL ORADOR:
- Tono conclusivo: “aportación científica” → lo más importante.
- **Gatillo:** “DevOps como catalizador”.
- Recordar que hay impacto doble: científico y social.
NOTAS AL ORADOR:
- Cerrar con solvencia: “intervención controlada y medible”.
- **Gatillo:** “método replicable → ordenar el bazar”.
- Rematar con una frase final clara antes del turno de preguntas.
NOTAS AL ORADOR:
- Mantener serenidad; pausa antes de responder.
- **Gatillo para preguntas clave:**
- Métricas → proceso, calidad, DX.
- Aislar efecto DevOps → comparación pre/post.
- Riesgo de no adopción comunitaria → mitigado con intervención gradual.