Proyecto de ASIR: ejemplos, ideas, memoria y pruebas
Actualizado el Pedro Puente Gil
El nombre oficial no es «TFG de ASIR». El Real Decreto 1629/2009 incluye el módulo 0379, Proyecto de Administración de Sistemas Informáticos en Red, dentro del título de Técnico Superior en ASIR. La búsqueda coloquial es útil para encontrar ejemplos; la norma y la programación de su centro son las que debe seguir al entregar.
El proyecto integra competencias de sistemas, redes, bases de datos, servicios, aplicaciones web, seguridad y alta disponibilidad. Eso no obliga a usar todas las tecnologías del ciclo. Obliga a diseñar una respuesta coherente, organizar su ejecución y demostrar que funciona dentro del alcance declarado.
Qué evalúa realmente el módulo 0379
El currículo estatal estructura el proyecto alrededor de cuatro resultados: identificar necesidades del sector, diseñar una solución, planificar su ejecución y definir seguimiento y control. Los criterios incluyen información, viabilidad, fases, recursos, riesgos, calidad, documentación, participación del usuario y control de cambios.
Por eso una instalación que «arranca» no basta. El tribunal necesita reconstruir por qué existe, qué requisitos cumple, cómo se desplegó, qué se probó y qué queda fuera. Antes de redactar el índice, conecte cada resultado de aprendizaje con una sección y una evidencia.
| Pregunta de evaluación | Evidencia posible |
|---|---|
| ¿Qué necesidad resuelve? | Escenario, usuarios, estado inicial y requisito |
| ¿Por qué esta arquitectura? | Alternativas, restricciones y decisión justificada |
| ¿Puede reproducirse? | Inventario, versiones, configuración y automatización |
| ¿Es segura y recuperable? | Modelo de amenazas, controles, backup y restauración |
| ¿Cumple lo prometido? | Matriz de pruebas, resultados e incidencias |
| ¿Puede mantenerse? | Monitorización, manuales, actualización y rollback |
Ejemplos reales: úselos para observar decisiones
El repositorio de Proyectos Integrados ASI/ASIR del IES Gonzalo Nazareno reúne proyectos de numerosos cursos. Hay alta disponibilidad, redes, identidad, contenedores, automatización, observabilidad, bases de datos y seguridad. Es una referencia más estable que copiar enlaces directos a PDF que cambian o dejan de responder.
Al revisar una memoria, no copie su índice. Anote el problema, el alcance, las alternativas, la arquitectura, el detalle reproducible y la calidad de las pruebas. Compruebe también qué falta: una memoria publicada no se convierte en modelo perfecto por haber sido aprobada.
Tres familias muestran bien la diferencia entre tema y proyecto:
- «Kubernetes» es un tema; una plataforma que recupera una aplicación tras la pérdida de un nodo, con objetivos de recuperación y pruebas, es un proyecto.
- «Monitorización» es un tema; detectar y diagnosticar la degradación de tres servicios con métricas, logs, umbrales y procedimiento de respuesta es un proyecto.
- «Active Directory» es un tema; migrar identidades y políticas de una pyme simulada, con segmentación, mínimos privilegios, backup y rollback, es un proyecto.
El valor está en la necesidad, los límites y la evidencia, no en acumular nombres de herramientas.
Elegir un alcance que llegue a pruebas
Empiece por un entorno concreto: una organización simulada, un laboratorio del centro, un servicio con carga definida o una infraestructura reproducible. A continuación identifique usuarios, activos, restricciones, nivel de servicio y criterios de aceptación.
Una idea es viable cuando dispone de recursos legales y técnicos, puede aislarse para no afectar sistemas reales y admite pruebas medibles. Si depende de créditos cloud, hardware, dominio, licencias o acceso de empresa, confirme la disponibilidad y prepare una alternativa local.
Evite presentar una auditoría ofensiva sobre sistemas de terceros. Use laboratorios propios y autorización expresa. No publique contraseñas, tokens, direcciones reales ni datos personales en capturas o repositorios.
Ideas planteadas como entregables verificables
En redes, puede diseñar la segmentación de una pyme ficticia, desplegar VLAN, enrutamiento, VPN y reglas y probar aislamiento, latencia y recuperación. En sistemas, una plataforma de identidades puede demostrar altas, bajas, grupos, políticas, mínimo privilegio y copia del directorio.
En disponibilidad, defina qué servicio protege, qué fallos simula y qué tiempo y pérdida de datos acepta. En automatización, compare el despliegue manual con un procedimiento idempotente, versionado y repetible. En observabilidad, relacione métricas, logs y alertas con incidentes concretos, evitando un panel vistoso que no conduce a ninguna acción.
Un proyecto de seguridad puede construir una línea base de hardening y validar controles en un laboratorio. Uno de bases de datos puede comparar replicación, consistencia, recuperación y coste bajo una carga definida. En todos ellos, reduzca el alcance hasta poder ensayar el caso nominal, el fallo y la recuperación.
Arquitectura y alternativas
Documente actores, componentes, redes, flujos, límites de confianza y datos. El diagrama debe corresponder con lo desplegado; si cambia la solución, versione el diseño. Incluya direccionamiento y puertos cuando sean relevantes, pero anonimize información sensible.
Compare alternativas con criterios antes de elegir. Coste, curva de aprendizaje, soporte, automatización, licencias, consumo, portabilidad, seguridad y operación pueden importar de forma diferente según el caso. Evite una tabla donde la herramienta preferida gana porque todos los pesos se han elegido después.
Declare supuestos: carga prevista, disponibilidad del laboratorio, duración de las pruebas o experiencia del operador. Una afirmación de alta disponibilidad sin escenario de fallo ni medición no está demostrada.
Implantación reproducible
Registre sistema operativo, versiones, topología, recursos y dependencias. Use control de versiones para scripts y configuración sin secretos. Cuando proceda, automatice provisión, configuración y despliegue; explique qué parte sigue siendo manual y por qué.
Las capturas son apoyo, no procedimiento. Una secuencia de pantallas sin comandos, archivos, decisiones ni validación envejece rápido y no permite repetir el trabajo. Lleve configuraciones extensas a anexos o repositorio y mantenga en el cuerpo los fragmentos que explican decisiones.
Documente incidencias mientras ocurren: síntoma, hipótesis, diagnóstico, cambio, resultado y aprendizaje. Una incidencia resuelta aporta evidencia de administración; esconderla solo rompe la trazabilidad.
Seguridad, copias y recuperación
Construya un inventario de activos y un modelo de amenazas proporcional. Separe redes y privilegios, gestione secretos fuera del repositorio, reduzca servicios expuestos, aplique actualizaciones y registre eventos relevantes.
Una copia no está validada hasta que se restaura. Defina qué se copia, con qué frecuencia, dónde se conserva y qué pérdida y tiempo de recuperación admite. Ejecute una restauración sobre un entorno limpio y anote duración, errores y comprobación de integridad.
Si usa servicios cloud, calcule costes con el escenario de pruebas y destruya recursos al terminar. No publique identificadores ni claves en la memoria. Si trabaja con datos de empresa, acuerde anonimización, embargo y entrega de configuraciones.
Diseñe pruebas antes de terminar el despliegue
Cada requisito necesita un método, preparación, resultado esperado, medida y evidencia. Incluya funcionamiento nominal, límites y fallos: caída de nodo, revocación de acceso, pérdida de conexión, restauración, saturación o rollback según el proyecto.
Separe verificación de validación. Comprobar que un balanceador reparte peticiones verifica una función; demostrar que la solución satisface la necesidad del escenario exige métricas y condiciones acordadas. No generalice un ensayo de laboratorio a producción sin explicar sus límites.
Una memoria que permita mantener el sistema
La plantilla del centro manda, pero la secuencia habitual debe conservar la lógica: contexto y objetivos, requisitos, alternativas, arquitectura, planificación, implantación, seguridad, pruebas, resultados, costes, conclusiones y manuales. Anexos e inventarios no deben obligar al tribunal a adivinar la decisión principal.
El presupuesto incluye infraestructura, licencias, consumo y una estimación de trabajo cuando la guía lo pida. El cronograma muestra dependencias y cambios reales, no solo el plan inicial. Las conclusiones responden a cada objetivo y distinguen cumplido, parcial y pendiente.
Prepare la defensa alrededor del problema, tres decisiones importantes y las pruebas. Lleve una demostración grabada como contingencia, pero no sustituya la explicación técnica. Debe poder justificar configuraciones, límites y recuperación sin depender de que el panel se vea bonito.
Si necesita convertir esos requisitos en un alcance realizable, podemos valorar un plan de apoyo para su proyecto final de ASIR a partir de la guía y los plazos de su centro.
Fuentes y ejemplos consultados
- BOE: Real Decreto 1629/2009, título de Técnico Superior en ASIR
- BOE: Orden EDU/392/2010, currículo del título de ASIR
- IES Gonzalo Nazareno: repositorio de Proyectos Integrados ASI/ASIR
- INCIBE: recursos y guías de ciberseguridad
- OWASP: proyectos y estándares de seguridad
Otros proyectos de Grado Superior
Preguntas frecuentes
¿El proyecto de ASIR es oficialmente un TFG?
El Real Decreto 1629/2009 lo denomina Proyecto de Administración de Sistemas Informáticos en Red, módulo 0379. TFG, proyecto final o proyecto integrado son expresiones habituales, pero la programación y la normativa del centro determinan el formato aplicable.
¿Qué debe incluir una memoria de ASIR?
Necesidad, alcance, requisitos, alternativas, arquitectura, implantación reproducible, seguridad, automatización, pruebas, incidencias, costes, planificación, resultados, límites y documentación de operación y recuperación. La plantilla del centro decide el orden y los anexos.
¿Qué tema de ASIR conviene elegir?
Uno que resuelva una necesidad concreta, pueda desplegarse en un entorno controlado y permita demostrar requisitos con pruebas. La tecnología más nueva no compensa un alcance inabarcable, dependencias inaccesibles o ausencia de recuperación y seguridad.
¿Hay que entregar capturas de pantalla?
Las capturas pueden complementar una evidencia, pero no sustituyen configuraciones versionadas, procedimientos, pruebas ni resultados. Deben mostrar algo relevante, ocultar secretos y acompañarse de contexto, versión y explicación.
¿Cuántas páginas debe tener el proyecto de ASIR?
No hay una extensión estatal única. Consulte la plantilla del centro y coloque en anexos configuraciones, inventarios o registros extensos. El cuerpo debe permitir comprender decisiones, implantación, pruebas y resultados sin depender de un número arbitrario de páginas.