METODOLOGÍA¶

Módulo profesional de Proyecto Intermodular del CFGS de Administración de Sistemas Informáticos en Red (ASIR). IES Macià Abela — Crevillent (Comunitat Valenciana). Docente: Francisco Javier Hernández Illán.

1. Enfoque general y metodologías activas¶

Para abordar el módulo de Proyecto Intermodular he optado por un enfoque basado en Aprendizaje Basado en Proyectos (ABP) y Aprendizaje Basado en Retos (ABR), alineado con el carácter «integrador y por retos» que define la normativa autonómica (Orden 8/2025 y Resolución de 17/07/2025), dentro del marco de la Ley Orgánica 3/2022 y del Real Decreto 659/2023.

Idea clave del módulo

El aula funciona como una simulación profesional sostenida en el tiempo. El alumnado no estudia tecnologías sueltas: opera una infraestructura completa que crece a lo largo del curso, como lo haría un departamento de sistemas en una pyme.

El curso entero gira en torno a un único proyecto de empresa, inspirado en organizaciones reales del tejido local de Crevillent (UNIFAM, CreviPlay, talleres mecánicos del polígono, etc.). Sobre esa base, en el día a día combino las siguientes metodologías activas.

1.1. Metodologías activas que combino¶

Aprendizaje Basado en Proyectos (ABP). Todo el curso gira alrededor de un mismo proyecto de empresa simulada. Cada actividad, cada práctica guiada y cada reto se incorpora a ese proyecto, que el grupo mantiene hasta la defensa final.
Aprendizaje Basado en Retos (ABR). Cada unidad de trabajo se materializa en un reto grupal numerado (RG301, RG401, RG501/RG502, RG601/RG602, RG701/RG702, RG801) con su rúbrica, sus entregables y su defensa. El alumnado siempre sabe qué tiene que producir y cómo se le va a evaluar.
Aprendizaje colaborativo. Trabajamos en grupos cooperativos de 2-3 personas con reparto explícito de roles (sistemas, red, base de datos, seguridad, documentación). Los bloqueos, los conflictos y los re-trabajos forman parte del aprendizaje; no se esconden.
Enfoque profesionalizante. Las herramientas no son didácticas: son las que el alumnado va a encontrar en su primer puesto de trabajo —Git, GitHub, Docker, Docker Compose, Terraform, Ansible, AWS (VPC, EC2, RDS, S3, CloudWatch, IAM), Bind9, Nginx, WordPress, MySQL, Prometheus, Pandora FMS, MkDocs Material—. Eso obliga a leer documentación oficial en inglés, interpretar logs reales y aprender a investigar de forma autónoma.
Resolución de incidencias como contenido. Los fallos no se ocultan: forman parte de la evaluación. Cada incidencia (un Security Group mal configurado, un volumen Docker no persistente, un ansible-playbook no idempotente, un DNS que no resuelve) entra en el cuaderno de incidencias del proyecto con causa raíz y solución aplicada.
Documentación técnica continua. La memoria no es un anexo final, sino un entregable vivo desde el día 1, escrito en Markdown y publicado con MkDocs Material sobre GitHub Pages. El alumnado interioriza rápido la regla del módulo: «si no está en la memoria, no existe».
Despliegue progresivo de infraestructura. Cada UT añade una capa al sistema:
```
red → cómputo → almacenamiento → aplicación → integración →
seguridad → automatización → operación
```
No se «monta un proyecto»: se opera una infraestructura que crece.

1.2. Conexión con los ejes técnicos del ciclo ASIR¶

Estas metodologías articulan los grandes contenidos del ciclo:

Eje técnico	Tecnologías que el alumnado maneja
Linux	Ubuntu Server 22.04, Debian 12
Redes y servicios	DHCP, DNS (Bind9), SSH, FTP, Apache, Nginx
Virtualización	GNS3, máquinas sobre LliureX
Contenedores	Docker, Docker Compose, redes y volúmenes
Automatización	Ansible, Terraform
Integración de servicios	Compose multi-servicio o varias EC2 conectadas
Administración de sistemas	Usuarios, firewall, hardening, copias
Documentación DevOps	IaC versionada, playbooks idempotentes, manuales reproducibles

Lo que separa a un estudiante de un profesional

El alumnado aprende a operar un sistema que no es suyo y que tiene que entender otra persona. Ese cambio de óptica —escribir y configurar pensando en quien vendrá después— es el salto real entre haber cursado el módulo y estar listo para trabajar.

2. Orientaciones metodológicas y retos formativos¶

El módulo se estructura en ocho unidades de trabajo (UT) que evolucionan a lo largo del curso con complejidad creciente. No son bloques independientes: cada UT añade una capa sobre la anterior, dentro de un mismo proyecto.

2.1. Las 8 unidades de trabajo¶

UT	Título	RA principal	Producto que se incorpora al proyecto
1	Herramientas del proyecto	RA3 · RA4	Entorno: Git, GitHub, MkDocs, Docker, GNS3, AWS
2	Planteamiento del reto y contexto	RA1 · RA2 · RA5	Caracterización de la empresa, DAFO, alcance, requisitos
3	Diseño de la solución y planificación	RA2 · RA5	Arquitectura, modelo de datos, EDT/WBS, cronograma, riesgos
4	Desarrollo iterativo y pruebas	RA3 · RA4	Stack desplegado (línea Docker o línea AWS)
5	Integración, seguridad y validación	RA3 · RA4	Stack integrado, hardening, monitorización
6	Despliegue y operación	RA3 · RA4	Infraestructura como código (Terraform) + Ansible
7	Documentación técnica y memoria	RA4 · RA5	Memoria publicada en GitHub Pages
8	Presentación, defensa y cierre	RA5	Defensa pública con demo en vivo

Cada UT cierra con un reto grupal de 30 puntos y rúbrica propia. Esto impone una cadencia clara, idéntica a la de un proyecto profesional:

planteamiento → diseño → desarrollo → integración → despliegue → documentación → defensa

2.2. Dos líneas paralelas: Docker y AWS¶

A partir de la UT3, cada grupo elige una línea técnica. Ambas comparten los mismos resultados de aprendizaje y la misma rúbrica integrada para la defensa final, pero permiten especializarse en un perfil profesional concreto.

Aspecto	Línea Docker (RG501 / RG601)	Línea AWS (RG502 / RG602)
Infraestructura	Docker Compose sobre host Linux	VPC, varias EC2, Elastic IP
Componentes	Nginx, WordPress, Laravel, MySQL	EC2 web, EC2 app, EC2 MySQL, EC2 DNS (Bind9)
Seguridad	Hardening Nginx, `/admin` protegido, backups probados	Security Groups, IAM/MFA, SSH endurecido
Observabilidad	Prometheus + Pandora FMS + logs Compose	CloudWatch + logs en instancia
Automatización (UT6)	Ansible sobre el host	Terraform + Ansible
Perfil profesional	Sysadmin Linux / contenedores	Administrador cloud

2.3. Orientaciones que aplico de forma sistemática¶

Trabajo incremental. El alumnado nunca empieza un reto desde cero: cada UT parte del entregable de la anterior. Lo desplegado en la UT4 se integra y asegura en la UT5, se automatiza en la UT6 y se documenta en la UT7.
Entregas parciales con rúbrica. No hay examen final único. Cada UT cierra con un entregable y una rúbrica pública publicada en Aules y aplicada abiertamente en clase. En algunos casos hay además defensa intermedia.
Integración continua. Versionamos todo en GitHub: código IaC, playbooks, docker-compose.yml, configuraciones y documentación. Cuando el grupo madura, los cambios pasan por Pull Requests revisados entre compañeros.
Validación técnica con criterios verificables. Cada reto define criterios objetivos:
- el sitio web responde en una URL determinada,
- la base de datos no es accesible desde fuera de su red,
- un segundo ansible-playbook devuelve changed=0 (idempotencia),
- terraform destroy && terraform apply reproduce el entorno completo,
- las copias se restauran correctamente.
Pruebas y pruebas negativas. El alumnado demuestra que lo que debe funcionar funciona, y que lo que no debe funcionar tampoco lo hace: acceso denegado a MySQL desde un origen no autorizado, /admin protegido, intentos de SSH sin clave bloqueados, etc. Las pruebas negativas son evidencia explícita en la rúbrica de la UT5.
Documentación permanente. Cada grupo mantiene desde el día 1 un sitio MkDocs con la memoria del proyecto. La reviso semanalmente. Si una decisión técnica no está documentada, no cuenta como hecha.
Defensa del trabajo realizado. El curso culmina con una defensa pública de 30-35 minutos ante tribunal:

Fase Duración

Presentación 10-12'

Demo funcional en vivo 8-10'

Defensa técnica + Q&A 8-10'

Autoevaluación + coevaluación 3-5'

Cualquier integrante debe poder responder sobre cualquier parte del proyecto: es el filtro real de la autoría compartida.
Mejora iterativa. Tras cada entrega devuelvo feedback concreto con la rúbrica delante. Las versiones siguientes incorporan ese feedback, igual que en las revisiones de código de una empresa.

Resultado al final del curso

Cada grupo termina con:

un proyecto realmente operable,
un repositorio Git con historial completo,
una memoria pública en GitHub Pages,
una infraestructura reproducible que cualquier integrante podría volver a levantar desde cero en pocos minutos.

3. Ecosistema tecnológico y herramientas de trabajo¶

La elección de herramientas define la cultura de trabajo del módulo. He optado por un ecosistema abierto, estándar de la industria y centrado en texto plano versionable, donde documentación, código e infraestructura se gestionan con las mismas técnicas.

Cuatro herramientas son centrales y sostienen el resto del stack:

flowchart LR
  A[**Aules**<br/>Moodle GVA] --> P[(Proyecto<br/>del grupo)]
  G[**GitHub**<br/>+ GitHub Pages] --> P
  M[**Markdown**] --> P
  K[**MkDocs Material**] --> P
  P --> Eval[Defensa final<br/>+ memoria publicada]

3.1. Aules — plataforma educativa (Moodle de la GVA)¶

Aules es la plataforma institucional de la Conselleria d'Educació, basada en Moodle. Es la columna vertebral pedagógica del módulo.

Funciones que cumple en el curso:

Planificación de sesiones: organización de las 8 UT, calendario de hitos y enlaces a los recursos publicados en GitHub Pages.
Seguimiento del alumnado: asistencia, calificación de cada reto, seguimiento por RA y registro acumulado de evidencias.
Comunicación: avisos, anuncios, mensajería interna y foros vinculados a cada UT.
Entrega de tareas con rúbrica importada en CSV (formato oficial vigente). El alumnado sube enlaces al repositorio, al sitio MkDocs, a los vídeos de demo y a las autoevaluaciones.
Organización del módulo: vista única del curso, autocontenida y accesible desde cualquier dispositivo, sin depender de servicios privativos.

Aules me proporciona trazabilidad completa de la evaluación y da al alumnado un único punto oficial donde consultar plazos, rúbricas y calificaciones.

3.2. GitHub — repositorio central de todos los proyectos¶

GitHub aloja tanto la guía docente del módulo (pi_asir) como el repositorio de cada grupo de alumnado.

Para qué lo usamos:

Control de versiones. Cada cambio en código, configuración (docker-compose.yml, *.tf, YAML de Ansible) y documentación queda registrado con autor, fecha y mensaje de commit.
Trabajo colaborativo. Ramas, Pull Requests, revisiones entre compañeros y fusiones a main. Es el flujo natural de cualquier equipo IT moderno.
Flujos profesionales. README.md, LICENSE, .gitignore, Issues para incidencias, Releases con etiquetas (v1.0-final) y, opcionalmente, workflows de GitHub Actions para publicar la memoria automáticamente.
Versionado de documentación. La memoria vive en /docs del repositorio, en Markdown, y se versiona igual que el código. Se convierte así en un artefacto auditable.
Trazabilidad del trabajo. El historial de commits y Pull Requests permite demostrar quién hizo qué y cuándo. En la defensa final es decisivo para evaluar la autoría compartida.

Cada grupo termina el curso con una URL pública a su memoria gracias a GitHub Pages, accesible para el tribunal, para las familias y, eventualmente, para reclutadores.

3.3. Markdown — formato único de redacción¶

Usamos Markdown para todo: apuntes, retos, rúbricas, memorias, manuales de usuario y de administrador.

Por qué Markdown:

Estándar de documentación técnica. Es el formato de facto en README de repositorios, wikis, plataformas como MkDocs/Hugo/Docusaurus y todo el ecosistema DevOps.
Simplicidad. El foco está en el contenido y la estructura, no en la maquetación. Reduce la barrera de entrada en las primeras semanas.
Reproducible y versionable. Es texto plano, diffeable en Git, libre de formatos propietarios y compatible con cualquier editor (VS Code, Cursor, vim, plugins de Aules). Funciona igual en Linux, Windows y macOS.
Estándar DevOps. La cultura Infrastructure as Code asume que todo es texto versionable. Los README de Docker, las guías de Ansible, la documentación de Terraform y las plantillas de AWS están escritas en Markdown.

Idea de fondo

En este módulo, escribir documentación es escribir código. La calidad del texto técnico es una competencia profesional en sí misma.

3.4. MkDocs Material — publicación web profesional¶

MkDocs Material convierte los Markdown del proyecto en un sitio web profesional. Para mí no es un capricho estético: obliga a que la documentación tenga una salida real, pública y verificable.

Qué obtiene el alumnado con MkDocs Material:

Sitio publicado con búsqueda, navegación lateral, modo claro/oscuro, admonitions, Mermaid para diagramas y resaltado de código, sin tocar HTML ni CSS.
Documentación viva: cada push a main despliega automáticamente la memoria en GitHub Pages. Nunca se queda «en local».
Organización estructurada: el mkdocs.yml obliga a pensar la memoria como un sitio jerárquico (portada, capítulos, anexos, glosario) y a separar diagramas, capturas y código en carpetas.
Apariencia técnica reconocible: el resultado se parece a la documentación oficial de Docker, Kubernetes, Terraform o FastAPI. Ver el propio trabajo presentado en ese formato cambia la percepción del alumnado.
Cultura open-source: las herramientas que usamos son proyectos libres; las configuraciones se comparten y cualquier mejora se puede contribuir.

3.5. Lo que aporta este ecosistema en conjunto¶

El conjunto Aules + GitHub + Markdown + MkDocs Material consigue, casi sin que el alumnado se dé cuenta, que adquiera hábitos profesionales reales:

genera documentación técnica continuamente,
mantiene proyectos versionados,
publica contenido técnico de forma automatizada,
trabaja con los flujos de cualquier equipo IT/DevOps.

Y conecta con conceptos centrales del sector:

Infraestructura como documentación. Lo que defines en *.tf y *.yml no es solo despliegue, también es la documentación más fiable del sistema.
Documentación reproducible. Una memoria escrita junto al código y publicada automáticamente es la única que no envejece.
Workflows modernos. Ramas, Pull Requests, revisiones, releases, despliegue continuo.
Cultura colaborativa. Trabajo asíncrono, discusión técnica por escrito, autoría rastreable.
Automatización. El módulo termina con alumnado capaz de pasar de un despliegue manual a uno como código aplicable con un único comando.

4. Agrupamientos del alumnado¶

La organización del aula varía según la actividad, pero mantengo un patrón estable durante todo el curso.

4.1. Modalidades de trabajo¶

Trabajo individual en las actividades de exploración inicial (instalación de Docker, primeros comandos de Git, primer sitio MkDocs, primeras prácticas de AWS Educate o GNS3) y en las autoevaluaciones de cada UT. Persigue consolidar los fundamentos antes de cooperar.
Trabajo en parejas en algunas prácticas guiadas (pair-troubleshooting sobre un Compose que no arranca o un playbook no idempotente) y en revisiones cruzadas de Pull Requests. Es el formato ideal para pensar en voz alta sobre el mismo problema técnico.
Grupos cooperativos de 2-3 personas como unidad de proyecto estable durante todo el curso. Cada grupo elige al inicio:
- una línea técnica (Docker o AWS),
- un caso de empresa local (UNIFAM, CreviPlay, taller mecánico, asociación local…),
y mantiene esa decisión hasta la defensa final.
Grupo-clase para presentación de retos, defensas intermedias, retrospectivas de UT, análisis conjunto de incidencias y discusión de decisiones de arquitectura.

4.2. Reparto de roles dentro del grupo cooperativo¶

Los roles se inspiran en equipos reales de administración de sistemas:

Rol	Áreas de responsabilidad
Sysadmin / Linux	Usuarios, permisos, firewall, copias de seguridad
Network / Cloud	Redes Docker o VPC, Security Groups, DNS
Database	MySQL/PostgreSQL, estructura de datos, backup y restore
AppDev / Web	WordPress/Laravel, stack web, integraciones
DevOps / Docs	Terraform, Ansible, MkDocs, Pull Requests, releases

Los roles rotan parcialmente para evitar la especialización rígida.

Regla para la defensa final

Toda persona del equipo debe entender toda la pila. En la defensa, el tribunal puede preguntar sobre cualquier parte del proyecto a cualquier integrante.

Las decisiones técnicas se documentan en el propio repositorio (en el Markdown del proyecto, en Issues o en comentarios de Pull Request), de modo que el alumnado se acostumbra a un flujo de decisión compartida y trazable, equivalente al de cualquier equipo IT profesional.

5. Tipos de actividades¶

A lo largo del curso implemento actividades muy variadas, todas anudadas al proyecto. Ninguna es un ejercicio suelto: cada actividad produce una evidencia que se incorpora al repositorio y a la memoria.

5.1. Actividades técnicas¶

Despliegue de servicios. Apache, Nginx, MySQL/PostgreSQL, WordPress, Laravel, Bind9, DHCP, FTP y SSH, en contenedores Docker o en instancias EC2.
Integración de sistemas. Conexión web–aplicación–base de datos extremo a extremo, redes Docker (frontend/backend), aislamiento con Security Groups, DNS interno y resolución de nombres entre componentes.
Administración Linux. Usuarios, permisos, servicios systemd, firewall (UFW o firewalld), tareas programadas, gestión de logs, hardening SSH y endurecimiento del SO sobre Ubuntu Server 22.04 o Debian 12.
Configuración de red. Topologías en GNS3, VPC en AWS con subredes públicas y privadas, Internet Gateway, Route Tables, Security Groups, Elastic IP y reglas de firewall en contenedores.
Automatización.
- Ansible: playbooks y roles (common, docker_host, nginx_proxy, backups, monitoring, web, app, db, dns, hardening), inventarios estáticos y dinámicos, templates Jinja2, variables, secretos con ansible-vault y verificación de idempotencia con --check --diff.
- Terraform (línea AWS): manifiestos (main.tf, variables.tf, outputs.tf) y ciclo init → plan → apply → destroy.
Resolución de incidencias. Diagnóstico de problemas reales: contenedores que no resuelven nombres, volúmenes que se pierden, conexiones MySQL bloqueadas por Security Group, certificados HTTPS mal emitidos, playbooks no idempotentes. Cada incidencia entra en el cuaderno de incidencias de la memoria.
Mantenimiento de infraestructura. Actualizaciones, verificación periódica de copias, restauración de respaldos a un entorno limpio, gestión de cambios mediante git revert + nuevo apply y comprobación recurrente de la idempotencia.

5.2. Actividades de validación y documentación¶

Pruebas funcionales y negativas.

Tipo	Ejemplos
Funcionales	«el sitio responde en `http://…`», «la persistencia se mantiene tras `docker compose down && up`»
Negativas	«el puerto 3306 no es accesible desde un origen no autorizado», «`/admin` exige autenticación», «un segundo `apply` no introduce cambios»

Documentación técnica. Memoria viva en Markdown, publicada con MkDocs Material en GitHub Pages. Estructura: caracterización, diseño y planificación, desarrollo, integración y seguridad, despliegue y operación, pruebas y evidencias, conclusiones y anexos (manuales de usuario y administrador, glosario, bibliografía).
Investigación autónoma. Lectura de documentación oficial en inglés (Docker, AWS, Terraform, Ansible, Bind9, Nginx, Material for MkDocs), búsqueda crítica de fuentes y uso responsable de IA con declaración explícita de uso, fuentes y licencias, conforme a los criterios de evaluación del módulo.

5.3. Actividades de exposición y profundización¶

Exposición oral y defensa técnica. Defensas intermedias por UT y defensa final pública ante tribunal (presentación 10-12', demo en vivo 8-10', Q&A 8-10', autoevaluación 3-5'). Se exige que todos hablen y que cualquiera responda sobre cualquier parte del proyecto.
Ampliación de funcionalidades. Actividades de profundización para alumnado que avanza más rápido: HTTPS con Certificate Manager, alarmas en CloudWatch, Prometheus + Pandora FMS, balanceadores, copias incrementales, Pull Requests revisados entre grupos. Se reconocen con puntos extra en la rúbrica.

5.4. Actividad transversal: AWS GameDay¶

Integro la participación en el AWS GameDay 2025 —campeonato nacional de retos en AWS— como simulación real de presión de producción: el alumnado resuelve incidencias en arquitecturas cloud bajo restricciones de tiempo. Es una de las actividades que mejor consolida la línea AWS y, además, una excelente oportunidad de exposición externa para el centro.

6. Cierre¶

La metodología de este módulo no pretende enseñar tecnologías una a una, sino formar profesionales capaces de operar una infraestructura completa, de documentar lo que hacen y de defenderlo ante un interlocutor técnico.

Cada decisión metodológica está orientada a ese objetivo:

el carácter por retos,
el desdoble en líneas Docker y AWS,
el uso intensivo de GitHub, Markdown y MkDocs Material,
el flujo de trabajo sobre Aules,
y la defensa final integradora.

Comparto esta misma metodología con los compañeros del centro socio Erasmus como base de un trabajo en red entre formaciones profesionales TIC europeas.

Material complementario: guion oral Erasmus.

Fase	Duración
Presentación	10-12'
Demo funcional en vivo	8-10'
Defensa técnica + Q&A	8-10'
Autoevaluación + coevaluación	3-5'