🎧 Audio del tema Escucha este breve audio para repasar las ideas principales este proyecto.
Dentro del proyecto de PC retro vamos a trabajar con una máquina muy interesante: el IBM PS/ValuePoint. No es tan mítico como un IBM PC XT, ni tan recordado como los PS/2, pero representa un momento muy importante de la historia del PC: el momento en el que IBM tuvo que aceptar que el mercado ya no giraba solo alrededor de sus estándares propietarios.
El IBM PS/ValuePoint fue una familia de ordenadores lanzada a comienzos de los años 90. Su objetivo era claro: ofrecer equipos IBM más competitivos, más parecidos a los PC compatibles del mercado y menos cerrados que la gama PS/2. La línea PS/ValuePoint apareció alrededor de 1992 y estuvo activa hasta mediados de los años 90, antes de ser sustituida por otras familias como IBM PC Series.
Para nuestro proyecto retro es una máquina ideal porque nos coloca justo en la época dorada del 486, de MS-DOS, de Windows 3.1, de los primeros entornos multimedia y de juegos como Doom, Monkey Island 2, Alone in the Dark, SimCity 2000, Wolfenstein 3D o Indiana Jones and the Fate of Atlantis.
¿Qué era el IBM PS/ValuePoint?
El IBM PS/ValuePoint fue una gama de ordenadores personales de IBM orientada a empresas, educación y usuarios que querían un PC fiable sin pagar el precio ni asumir las limitaciones de algunas decisiones propietarias de IBM.
Venía de una época complicada para IBM. La empresa había creado el estándar PC original, pero después intentó recuperar control con la gama PS/2, que utilizaba tecnologías como el bus Micro Channel Architecture, más cerrado y menos compatible con las tarjetas habituales del mercado. El problema es que el mundo del PC compatible ya iba por libre: placas base clónicas, tarjetas ISA, discos IDE, tarjetas VGA/SVGA y componentes más económicos.
El PS/ValuePoint fue una respuesta a esa situación. Era un IBM, sí, pero mucho más cercano al PC estándar que podía montar cualquier fabricante. En lugar de apostar por un ecosistema cerrado, estos equipos usaban componentes más comunes en el mercado, como buses ISA/VLB/PCI según modelo, discos IDE y tarjetas de expansión más convencionales.
Dicho de forma sencilla: el PS/ValuePoint fue IBM bajando a la tierra del PC compatible.
Modelos y formatos
La familia PS/ValuePoint tuvo varios formatos físicos. Entre los más representativos estaban:
Formato
Ejemplo de tipo
Descripción
Space saving desktop
6382 /S
Caja horizontal compacta, menos ranuras y bahías
Desktop
6384 /D
Sobremesa horizontal más grande
Mini Tower
6387 /T
Torre pequeña, más ampliable
Algunos documentos de mantenimiento de IBM mencionan modelos como 425SX, 433SX, 433DX, 466DX2 y variantes en formato /S, /D y /T. Estos nombres suelen indicar el tipo de procesador: por ejemplo, un 466DX2 hace referencia a un 486DX2 a 66 MHz.
Para emulación en 86Box, una configuración muy interesante es un IBM PS/ValuePoint 433DX o 466DX2, porque representa muy bien un PC de mediados de los 90 sin irnos todavía a la era Pentium.
Especificaciones típicas
Las configuraciones variaban mucho según modelo, pero una máquina representativa podía tener algo parecido a esto:
Componente
Configuración típica
Procesador
Intel 486SX, 486DX, 486DX2 o incluso DX4 en algunos modelos
Frecuencia
25, 33, 50, 66 o 100 MHz según versión
Memoria RAM
4 MB, 8 MB, 16 MB o más
Disco duro
IDE, normalmente entre 120 MB y 500 MB en configuraciones habituales
Disquetera
3.5” de 1.44 MB
Vídeo
VGA/SVGA, a menudo integrado en placa
Sonido
No siempre incluido; se podía añadir Sound Blaster u otra ISA
Sistema operativo
PC DOS, MS-DOS, Windows 3.1, OS/2 o posteriormente Windows 95
Algunas referencias de IBM para modelos ValuePoint muestran configuraciones con procesadores 486SX-25, 486DX-33, 486DX2-50 y 486DX2-66, memoria de 4 u 8 MB, discos de 120 MB o 170 MB y PC DOS 5.02 con Windows 3.1 en ciertos modelos.
¿Por qué es interesante para un proyecto retro?
El IBM PS/ValuePoint es perfecto para un proyecto de PC retro por varias razones.
Primero, porque representa una época muy concreta: el salto desde los PC puramente de oficina hacia los PC multimedia. Es la etapa en la que todavía se trabaja mucho con MS-DOS, pero Windows empieza a ganar protagonismo.
Segundo, porque es una máquina suficientemente potente para ejecutar muchos juegos clásicos de DOS, pero no tan moderna como para perder la sensación retro. Un 486DX2 a 66 MHz sigue teniendo limitaciones, y eso es parte de la gracia.
Tercero, porque permite explicar conceptos históricos muy útiles:
Diferencias entre IBM PC, PS/2 y PS/ValuePoint.
Evolución de ISA, VLB y PCI.
Importancia del disco IDE.
Papel de MS-DOS y Windows 3.1.
Primeros pasos del PC multimedia.
Tarjetas de sonido compatibles Sound Blaster.
Configuración manual de memoria convencional, EMS y XMS.
Y cuarto, porque en 86Box podemos recrearlo sin necesidad de tener el hardware real.
Programas recomendados
Además de juegos, podemos instalar software de la época para darle más sentido al proyecto.
Programa
Uso
MS-DOS 6.22
Sistema base clásico
Windows 3.11
Entorno gráfico de la época
Norton Commander
Gestión de archivos
Microsoft Works
Ofimática ligera
WordPerfect
Procesador de textos clásico
Paintbrush
Dibujo básico en Windows
WinZip antiguo
Compresión de archivos
QBasic
Programación básica en DOS
Turbo Pascal
Programación clásica
Borland C++
Desarrollo en C/C++
Doom Setup
Configuración de sonido, teclado y vídeo
Configurar un IBM PS/ValuePoint en 86Box
En esta práctica vamos a crear una máquina virtual en 86Box que simule un IBM PS/ValuePoint basado en 486. Después prepararemos el disco duro, instalaremos MS-DOS, añadiremos soporte para CD-ROM, configuraremos una tarjeta de sonido y dejaremos el sistema listo para instalar juegos y programas clásicos.
Material necesario
Antes de empezar necesitamos:
Elemento
Uso
86Box instalado
Emulador de PC clásico
ROMs de 86Box
Necesarias para arrancar las máquinas
Imagen de disquete de MS-DOS 6.22
Instalación del sistema operativo
Imagen ISO o carpeta con juegos/programas
Software para instalar
Imagen de drivers de Sound Blaster
Para configurar sonido
Imagen o driver de CD-ROM
Por ejemplo OAKCDROM.SYS
Tiempo y paciencia
Muy necesario en informática retro
Importante: 86Box emula hardware de forma más realista que otros emuladores. Eso significa que a veces hay que configurar BIOS, discos, controladoras y drivers como se hacía en los años 90.
Configuración recomendada
Para empezar, recomiendo una configuración equilibrada:
Apartado
Valor recomendado
Máquina
IBM PS/ValuePoint 433DX o 466DX2, si está disponible
CPU
Intel 486DX2 a 66 MHz
RAM
16 MB
Vídeo
SVGA integrado o compatible
Disco duro
IDE de 504 MB
Disquetera
3.5” 1.44 MB
CD-ROM
IDE ATAPI
Sonido
Sound Blaster 16 ISA
Sistema operativo
MS-DOS 6.22 + Windows 3.11
Alternativa
Windows 95 si se quiere probar algo más moderno
86Box sigue actualizándose y ha recibido correcciones relacionadas con modelos IBM PS/ValuePoint, por ejemplo en versiones recientes se mencionan ajustes sobre el vídeo integrado del IBM PS/ValuePoint 433DX/Si.
Paso 1. Crear una nueva máquina en 86Box
Abrimos 86Box y creamos una nueva configuración.
Abrimos 86Box.
Creamos una nueva máquina.
Elegimos una categoría de equipos 486.
Buscamos un modelo relacionado con IBM PS/ValuePoint.
Seleccionamos un modelo como:
IBM PS/ValuePoint 433DX
IBM PS/ValuePoint 466DX2
IBM PS/ValuePoint P60, si queremos probar una configuración más moderna tipo Pentium.
Para este post recomiendo trabajar con un 486DX2, porque es más representativo de la época DOS/Windows 3.1.
Paso 2. Configurar el procesador
En la sección de CPU seleccionamos:
Opción
Valor
Procesador
Intel 486DX2
Velocidad
66 MHz
FPU
Integrada, si usamos DX/DX2
Modo dinámico
Activado si 86Box lo permite
Un 486DX2 a 66 MHz es una configuración excelente para juegos de 1992-1994.
Paso 3. Configurar la memoria RAM
Configuramos la memoria en:
Uso
RAM recomendada
Solo MS-DOS
4 MB u 8 MB
MS-DOS + Windows 3.1
8 MB o 16 MB
Windows 95
16 MB o 32 MB
Para esta práctica usaremos:
16 MB de RAM
Es suficiente para DOS, Windows 3.11 y una buena cantidad de juegos.
Paso 4. Configurar el disco duro
Creamos un disco duro IDE.
Recomendación:
Parámetro
Valor
Tipo
IDE
Tamaño
504 MB
Formato
Imagen nueva
Uso
Sistema operativo + juegos
¿Por qué 504 MB? Porque muchos equipos antiguos tenían limitaciones de BIOS con discos grandes. Para evitar problemas, es mejor empezar con un disco pequeño y compatible. En conversaciones de usuarios reales sobre PS/ValuePoint se mencionan límites prácticos cercanos a 500 MB en algunos modelos 6382.
Paso 5. Añadir disquetera
Configuramos una disquetera:
Opción
Valor
Unidad A:
3.5” 1.44 MB
Imagen inicial
Disco 1 de MS-DOS 6.22
Esto nos permitirá arrancar el instalador de MS-DOS.
Paso 6. Añadir CD-ROM
Añadimos una unidad de CD-ROM IDE/ATAPI.
Opción
Valor recomendado
Tipo
IDE ATAPI CD-ROM
Canal
Secundario maestro, si está disponible
Uso
Instalar juegos, drivers y Windows
Si el CD-ROM no aparece dentro de DOS, no es un fallo raro. En MS-DOS hay que cargar un driver en CONFIG.SYS y después MSCDEX.EXE en AUTOEXEC.BAT.
Paso 7. Configurar tarjeta de sonido
Añadimos una tarjeta de sonido compatible.
Recomendación:
Opción
Valor
Tarjeta
Sound Blaster 16
Puerto
220
IRQ
5 o 7
DMA
1
High DMA
5
MPU-401
330
Configuración típica:
BLASTER=A220 I5 D1 H5 P330 T6
Esta configuración será importante para juegos como Doom, Duke Nukem II o Monkey Island 2.
Paso 8. Primer arranque
Montamos el primer disquete de MS-DOS 6.22 y arrancamos la máquina.
Si todo va bien, aparecerá el instalador de MS-DOS.
Si aparece un error del tipo “no boot disk” o “no system disk”, revisamos:
Que el disquete esté montado en la unidad A:
Que el orden de arranque permita arrancar desde disquete.
Que la imagen del disquete sea arrancable.
Que la máquina tenga una disquetera configurada.
Crear partición con FDISK
Si el disco está vacío, MS-DOS necesitará crear una partición.
Desde el disquete de arranque podemos ejecutar:
FDISK
Dentro de FDISK:
Crear partición primaria DOS.
Usar todo el tamaño del disco.
Marcar la partición como activa.
Salir de FDISK.
Reiniciar la máquina.
Importante: después de crear la partición hay que reiniciar. Si no reiniciamos, DOS puede no reconocer correctamente el disco.
Formatear el disco duro
Después de reiniciar con el disquete de DOS, ejecutamos:
FORMAT C: /S
Esto formatea el disco C: y copia los archivos básicos del sistema para que pueda arrancar.
Cuando termine, podemos poner una etiqueta al disco, por ejemplo:
VALUEPOINT
Instalar MS-DOS
Ejecutamos el instalador desde el disquete:
A: SETUP
Seguimos los pasos del instalador e iremos cambiando los disquetes cuando nos lo pida.
Al finalizar, quitamos el disquete y reiniciamos.
Si todo ha ido bien, el sistema arrancará desde el disco duro C:.
Configurar el CD-ROM en MS-DOS
Para que MS-DOS detecte el CD-ROM necesitamos un driver. Uno de los más habituales es:
OAKCDROM.SYS
Podemos copiarlo a una carpeta, por ejemplo:
C:\CDROM
Creamos la carpeta:
MD C:\CDROM
Copiamos el driver:
COPY A:\OAKCDROM.SYS C:\CDROM
Editamos CONFIG.SYS:
EDIT C:\CONFIG.SYS
Añadimos:
DEVICE=C:\CDROM\OAKCDROM.SYS /D:MSCD001
Ahora editamos AUTOEXEC.BAT:
EDIT C:\AUTOEXEC.BAT
Añadimos:
C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D
Reiniciamos.
Si todo va bien, el CD-ROM aparecerá como unidad D:.
Configurar memoria para juegos
Muchos juegos de DOS necesitan memoria convencional libre. Podemos mejorar la configuración usando HIMEM.SYS y EMM386.EXE.
Una de las formas más cómodas de pasar archivos desde nuestro equipo moderno a una máquina emulada en 86Box es crear una imagen ISO. Esta imagen se comportará como si fuera un CD-ROM real dentro del ordenador emulado.
Para hacerlo podemos utilizar ImgBurn, una herramienta clásica para crear y grabar imágenes de disco. Aunque su interfaz tiene un aspecto algo antiguo, sigue siendo muy útil para este tipo de tareas retro.
La idea es sencilla: primero preparamos una carpeta en nuestro ordenador con todos los archivos que queremos llevar a MS-DOS o Windows 9x, y después convertimos esa carpeta en un archivo .iso.
Por ejemplo, podemos crear una carpeta llamada:
C:\CD_86BOX
Dentro de esa carpeta podemos meter juegos, drivers, utilidades, instaladores o cualquier archivo que queramos usar dentro de la máquina virtual:
Una vez preparada la carpeta, abrimos ImgBurn y seleccionamos la opción:
Create image file from files/folders
Esta opción permite crear una imagen ISO a partir de una carpeta de nuestro disco duro.
Después añadimos la carpeta que hemos preparado, elegimos dónde queremos guardar la imagen ISO resultante y pulsamos el botón para crearla. Por ejemplo, podemos guardar el archivo como:
C:\ISOS\cd_86box.iso
Cuando termine el proceso, ya tendremos un CD-ROM virtual listo para usar en 86Box.
Instalación de Windows 3.11 desde una ISO de CD-ROM
Una vez que el IBM PS/ValuePoint ya tiene MS-DOS instalado, el siguiente paso lógico es añadir un entorno gráfico clásico. Para este proyecto vamos a instalar Windows 3.11 desde una imagen ISO montada como CD-ROM en 86Box.
Aunque Windows 3.11 se distribuía normalmente en disquetes, para trabajar de forma más cómoda en el emulador podemos preparar una ISO con los archivos de instalación. Esto facilita mucho el proceso, evita tener que cambiar disquetes constantemente y nos permite tener en un único CD virtual tanto Windows como drivers, utilidades y pequeños programas de la época.
Requisitos previos
Antes de empezar, el sistema debe tener:
Elemento
Estado necesario
MS-DOS
Instalado y arrancando desde C:
CD-ROM
Detectado como unidad D:
Driver CD-ROM
OAKCDROM.SYS cargado en CONFIG.SYS
MSCDEX
Cargado en AUTOEXEC.BAT
Ratón
Recomendable, aunque no imprescindible
RAM
Mínimo 4 MB, recomendado 8 MB o 16 MB
Para comprobar que el CD-ROM funciona, desde DOS podemos escribir:
D: DIR
Si aparece el contenido del CD, ya podemos continuar con la instalación.
Durante la instalación de Windows para Trabajo en Grupo 3.11, Microsoft solicitaba un nombre de usuario, una organización y un número de producto. Este número venía normalmente en la tarjeta de registro, en la documentación original o en el material incluido con la licencia del programa.
A diferencia de las versiones modernas de Windows, este número no funcionaba como una activación online. En aquella época no existía todavía el sistema de validación por Internet que asociamos a Windows XP, Windows 10 o Windows 11. El instalador simplemente pedía el dato como parte del proceso de registro e identificación del producto.
Esto refleja muy bien cómo era el software comercial de principios de los años 90: el control de licencia dependía mucho más de la documentación física, los manuales, los certificados de autenticidad, las etiquetas y los disquetes o CD originales. El número de producto servía para identificar la copia instalada y facilitar el soporte técnico, pero el sistema no se conectaba a ningún servidor para comprobarlo.
En nuestro caso, dentro del laboratorio retro con 86Box, esta pantalla resulta curiosa porque nos recuerda una época en la que instalar Windows era también un pequeño ritual: escribir el nombre, la empresa, el número del producto, elegir componentes, seleccionar el tipo de pantalla, configurar impresoras y terminar arrancando el clásico Administrador de programas.
Una vez instalado ponemos en la terminal:
win
Instalar DOOM desde una imagen de CD
Para instalar DOOM en nuestro IBM PS/ValuePoint emulado con 86Box, he optado por un método sencillo y bastante cómodo: crear una imagen ISO con los archivos del juego y montarla como si fuera un CD-ROM dentro de la máquina virtual.
Una vez creada la ISO y configurado correctamente el lector de CD-ROM en MS-DOS, el sistema detecta la unidad como D:. Desde ahí podemos comprobar el contenido del disco con:
D: DIR
En este caso, la imagen contiene directamente los archivos del juego, así que no necesitamos un instalador complejo. Basta con crear una carpeta en el disco duro de la máquina y copiar allí el contenido del CD.
Por ejemplo:
C: CD \ MD DOOM COPY D:\*.* C:\DOOM
Si el juego está dentro de una carpeta del CD, por ejemplo D:\DOOM, usaríamos:
C: CD \ MD DOOM COPY D:\DOOM\*.* C:\DOOM
Después entramos en la carpeta del juego:
CD \DOOM DIR
Y buscamos el ejecutable principal. Normalmente encontraremos archivos como:
DOOM.EXE SETUP.EXE README.TXT
Antes de jugar conviene ejecutar el programa de configuración:
SETUP
Desde ahí podemos ajustar el sonido, la música y los controles. En una máquina emulada es habitual tener que probar varias opciones de sonido hasta encontrar la que mejor funciona.
Finalmente, para ejecutar el juego:
DOOM
Si el juego arranca pero no reconoce el ratón, no es un fallo de DOOM: MS-DOS necesita tener cargado previamente un controlador de ratón, como CTMOUSE.EXE o MOUSE.COM. Que el ratón funcione en Windows 3.11 no significa necesariamente que esté disponible también para los juegos de DOS.
Este método de instalación es muy práctico porque nos permite preparar los archivos cómodamente desde nuestro ordenador actual, crear una ISO y usarla en 86Box como si fuera un CD real. Para un proyecto retro, además, mantiene bastante bien la sensación de estar trabajando con hardware y software de la época.
En este primer módulo vamos a sentar las bases del curso. Antes de aprender a hacer README, manuales, esquemas o documentación profesional, es importante entender qué es realmente la documentación técnica, por qué es tan importante y por qué en tantos proyectos termina siendo un desastre o directamente no existe.
La idea de esta unidad es que el alumno comprenda que documentar no es “rellenar papel”, sino una parte fundamental del trabajo técnico. Un proyecto mal documentado puede convertirse en un problema incluso aunque técnicamente esté bien hecho.
En este módulo se trabajará:
qué es la documentación técnica
por qué suele fallar la documentación en proyectos reales
diferencias entre documentar para uno mismo, para un equipo y para un cliente
tipos de documentación en informática
¿Qué es la documentación técnica?
La documentación técnica es el conjunto de textos, esquemas, instrucciones, referencias y evidencias que explican cómo funciona un sistema, cómo se instala, cómo se usa, cómo se mantiene o cómo se ha construido.
Dicho de forma sencilla: la documentación técnica sirve para que una persona pueda entender, usar, mantener, revisar o continuar un trabajo técnico sin depender totalmente de quien lo creó.
Ejemplos de documentación técnica
En informática, documentación técnica puede ser por ejemplo:
un README de un proyecto en GitHub
un manual de instalación de un servidor
una guía de despliegue de una aplicación
un documento con la arquitectura de una red
un procedimiento para hacer copias de seguridad
una memoria técnica de un proyecto
un informe de auditoría o de incidencia
una wiki interna con procesos y configuraciones
¿Por qué es tan importante documentar?
Porque en el mundo real los proyectos no viven solo el día que se crean.
Un proyecto técnico normalmente pasa por varias fases:
se diseña
se implementa
se prueba
se entrega
se mantiene
se modifica
se corrige
se reutiliza o amplía
Si no existe documentación, todo depende de la memoria de una persona. Y eso provoca errores, pérdida de tiempo, dependencia del autor original y muchos problemas cuando hay que revisar o retomar el trabajo.
Una idea clave
Un proyecto sin documentación puede funcionar hoy, pero convertirse en un problema mañana.
¿Qué suele pasar en los proyectos reales?
En muchísimos proyectos la documentación falla por motivos muy parecidos.
Problemas habituales
no se documenta desde el principio
se deja “para el final”
se escribe deprisa y sin estructura
se da por hecho que cosas importantes “ya se entienden”
se documenta pensando solo en quien lo ha hecho
la documentación se queda desactualizada
no se distingue entre tipos de documento
se mezcla información técnica, organizativa y personal sin orden
no se incluyen evidencias, validaciones ni contexto
Resultado de todo esto
Al final aparecen documentos que:
no sirven para instalar nada
no explican bien el proyecto
no ayudan a otra persona
no permiten reproducir el trabajo
quedan abandonados
generan confusión en lugar de ayudar
Documentar no es escribir mucho
Uno de los errores más frecuentes es pensar que “más texto” significa “mejor documentación”.
No siempre es así.
Una buena documentación no tiene por qué ser enorme. Tiene que ser:
clara
ordenada
útil
precisa
fácil de consultar
pensada para quien la va a leer
Hay documentación breve que funciona muy bien, y documentación larguísima que no sirve para nada.
¿Para quién se documenta?
Esta es una de las preguntas más importantes del módulo.
No se documenta igual para todos los destinatarios. La forma de documentar cambia mucho según quién va a leer el documento.
Documentar para uno mismo
Cuando una persona documenta para sí misma, normalmente busca:
recordar pasos
guardar comandos
anotar configuraciones
dejar registro de errores y soluciones
construir una base de conocimiento personal
Características habituales
más libertad en el formato
lenguaje más directo
menos contexto general
más valor práctico inmediato
organización pensada para el propio autor
Ejemplo
Una nota en Obsidian con comandos para configurar Apache y MySQL en Ubuntu.
Documentar para un equipo
Cuando se documenta para un equipo, la documentación debe ser más clara, más ordenada y más estandarizada.
Aquí ya no basta con que “yo lo entienda”. Tiene que entenderlo otra persona que quizá no estuvo presente durante el proceso.
Características habituales
lenguaje más claro y neutral
estructura estable
pasos reproducibles
mayor precisión
contexto suficiente
convenciones compartidas
mantenimiento continuo
Ejemplo
Una guía interna para desplegar una aplicación web en un servidor de pruebas.
Documentar para un cliente o para una entrega formal
Aquí la documentación debe tener además una presentación más cuidada y una explicación más completa del contexto, objetivos y resultados.
Características habituales
tono más profesional
mejor presentación visual
organización muy clara
explicación de objetivos, alcance y resultados
vocabulario comprensible para perfiles no tan técnicos
formato más formal: Word, PDF, memoria, informe, etc.
Ejemplo
La memoria técnica de un proyecto final, con portada, índice, imágenes, fases, decisiones técnicas y conclusiones.
Comparativa rápida
Tipo de documentación
Destinatario
Objetivo principal
Estilo habitual
Personal
Uno mismo
Recordar y reutilizar
Directo y práctico
De equipo
Compañeros o técnicos
Compartir conocimiento y mantener procesos
Claro, estructurado y reproducible
Formal o de cliente
Profesorado, cliente, responsables, tribunal
Explicar, justificar y entregar
Profesional, completo y bien presentado
Tipos de documentación en informática
En informática no existe un solo tipo de documentación. Hay varias categorías, y cada una cumple una función diferente.
Entender esto es muy importante porque muchos errores vienen de mezclarlo todo en un solo documento.
1. Documentación de producto
Es la documentación que explica un producto, una aplicación, un sistema o una herramienta concreta.
Suele incluir
qué es
para qué sirve
cómo se instala
cómo se configura
cómo se usa
qué requisitos tiene
qué estructura interna presenta
Ejemplos
README de una aplicación
manual de usuario técnico
documentación de API
guía de instalación de software
2. Documentación de proceso
Explica cómo se realiza una tarea o un conjunto de tareas.
No se centra tanto en “qué es el producto”, sino en qué pasos hay que seguir para hacer algo correctamente.
Suele incluir
objetivo del proceso
requisitos previos
secuencia de pasos
validación
problemas frecuentes
resultado esperado
Ejemplos
procedimiento de despliegue
guía de copia de seguridad
proceso de alta de usuarios
checklist de hardening
guía de restauración de servicios
3. Documentación operativa
Es la documentación que sirve para operar, administrar o mantener sistemas en funcionamiento.
Está muy relacionada con ASIR, sistemas, administración, redes y explotación técnica.
Suele incluir
configuraciones
servicios
puertos
rutas
comandos
validaciones
acciones de mantenimiento
actuación ante fallos
Ejemplos
runbook de administración
guía de reinicio de servicios
procedimientos de monitorización
documentación de una infraestructura de red
inventario técnico de máquinas o servicios
4. Documentación de soporte
Es la documentación pensada para resolver dudas, incidencias o problemas recurrentes.
Suele incluir
preguntas frecuentes
errores comunes
pasos de comprobación
diagnósticos básicos
soluciones conocidas
Ejemplos
FAQ técnica
base de conocimiento
guía de resolución de incidencias
documentación de errores frecuentes
5. Documentación académica y de entrega
Es muy habitual en entornos educativos, proyectos fin de ciclo, memorias, prácticas guiadas y entregas técnicas.
Aquí no solo importa el funcionamiento, sino también explicar el proceso, justificar decisiones y demostrar el trabajo realizado.
Suele incluir
introducción
objetivos
análisis
requisitos
diseño
implementación
capturas
pruebas
conclusiones
bibliografía o referencias
Ejemplos
memoria de TFG o TFM
entrega de una práctica técnica
informe de laboratorio
documentación de un proyecto de clase
6. Documentación viva vs. documentación abandonada
Este punto es especialmente importante.
Documentación viva
Es la que se mantiene actualizada y sigue siendo útil con el paso del tiempo.
Características
se revisa
se corrige
se adapta a cambios
refleja el estado real del proyecto
acompaña al trabajo técnico
Documentación abandonada
Es la que se escribió una vez y nunca más se revisó.
Problemas típicos
comandos que ya no sirven
capturas antiguas
rutas que han cambiado
versiones desactualizadas
información incompleta o engañosa
Idea importante
Una documentación antigua puede ser peor que no tener documentación, porque da una falsa sensación de confianza.
Ejemplo sencillo para entenderlo
Imagina una práctica donde un alumno monta un servidor web con Apache, PHP y MySQL.
Si documenta bien:
explica requisitos
indica comandos
organiza pasos
muestra validaciones
añade errores encontrados
incluye estructura del proyecto
deja claro cómo reproducirlo
Si documenta mal:
pone cuatro comandos sueltos
no indica orden
no explica qué instaló realmente
no muestra resultado
no aclara versiones ni rutas
no se entiende qué hizo ni cómo repetirlo
Técnicamente puede haber hecho lo mismo, pero el valor del trabajo cambia muchísimo.
Errores muy frecuentes al empezar a documentar
Estos errores conviene enseñarlos desde el principio:
escribir pensando “ya me acordaré”
no poner títulos claros
mezclar teoría y práctica sin orden
usar frases ambiguas
copiar comandos sin explicar para qué sirven
no validar resultados
no anotar problemas reales
no diferenciar entre borrador y versión final
documentar solo el resultado y no el proceso
Ejemplos
Caso
Tipo de documentación
Destinatario
Observación
README de instalación
Documentación de producto
Usuario técnico o desarrollador
Explica qué es y cómo usarlo
Documento en Word con memoria
Documentación académica y de entrega
Profesorado, cliente o tribunal
Presentación formal
Nota de Obsidian con comandos
Documentación personal u operativa
Uno mismo
Uso interno y práctico
Guía de despliegue en Apache
Documentación de proceso u operativa
Equipo técnico
Procedimiento reproducible
Lista de errores frecuentes
Documentación de soporte
Usuarios o técnicos
Ayuda a resolver incidencias
Documento obsoleto
Documentación abandonada
Puede confundir a cualquiera
No refleja la realidad actual
Ideas clave para recordar
Documentar no es decorar un proyecto: es hacerlo comprensible y mantenible.
Una buena documentación ayuda a repetir, mantener, explicar y mejorar un trabajo técnico.
No toda la documentación sirve para lo mismo: hay que elegir bien el tipo de documento.
La documentación útil está pensada para quien la va a leer.
Una documentación sin mantenimiento termina perdiendo valor.
Caso de uso: despliegue de una aplicación web interna para gestión de incidencias
Una pequeña empresa llamada NetSecure Solutions necesita una aplicación web interna para que el equipo técnico pueda registrar incidencias informáticas, asignarlas a distintos técnicos y hacer seguimiento de su resolución.
Un desarrollador del equipo ha creado una primera versión de la aplicación usando:
PHP
MySQL
Apache
JavaScript
HTML y CSS
La aplicación funciona, pero ahora surge un problema habitual en muchos proyectos técnicos:
el sistema debe instalarse también en otro servidor
otros técnicos tienen que poder mantenerlo
un responsable debe entender qué incluye el proyecto
si aparece un error, alguien debe saber cómo revisarlo
si el desarrollador original no está, el trabajo debe poder continuar
Para evitar depender únicamente de la memoria del autor, el equipo decide crear una documentación técnica completa del proyecto.
¿Qué documentación necesitarían?
En este caso podrían necesitar, por ejemplo:
un README principal para explicar el proyecto
una guía de instalación para desplegarlo en otro equipo
una guía de configuración de la base de datos
una documentación de estructura del proyecto
una guía operativa para revisar logs y reiniciar servicios
una base de incidencias frecuentes
una memoria técnica para presentar el proyecto a dirección o a un cliente
¿Por qué este caso de uso es bueno para el módulo?
Porque permite ver claramente que:
no toda la documentación sirve para lo mismo
un único documento no siempre es suficiente
el destinatario cambia según el documento
un proyecto técnico necesita más de un tipo de documentación
Ejemplo de índice
A continuación tienes un índice de ejemplo para la documentación de este proyecto ficticio. Te puede servir para enseñar a los alumnos cómo se organiza un documento técnico amplio.
Índice de ejemplo: Documentación técnica del proyecto “NetSecure Tickets”
1. Introducción
1.1. Descripción general del proyecto 1.2. Objetivo de la aplicación 1.3. Alcance del sistema 1.4. Público al que va dirigida esta documentación
2. Visión general del proyecto
2.1. Problema que resuelve 2.2. Funcionalidades principales 2.3. Tecnologías utilizadas 2.4. Estructura general de funcionamiento
3. Requisitos previos
3.1. Requisitos de hardware 3.2. Requisitos de software 3.3. Versiones recomendadas 3.4. Dependencias necesarias
4. Instalación del entorno
4.1. Instalación de Apache 4.2. Instalación de PHP 4.3. Instalación de MySQL 4.4. Configuración inicial del servidor 4.5. Verificación del entorno
5. Despliegue de la aplicación
5.1. Copia de archivos del proyecto 5.2. Estructura de carpetas 5.3. Configuración de conexión a base de datos 5.4. Importación de la base de datos 5.5. Prueba inicial de funcionamiento
6. Uso básico de la aplicación
6.1. Pantalla principal 6.2. Registro de incidencias 6.3. Consulta de incidencias 6.4. Asignación a técnicos 6.5. Cierre de incidencias
7. Estructura técnica del proyecto
7.1. Organización de archivos 7.2. Archivos principales 7.3. Relación entre frontend y backend 7.4. Base de datos y tablas utilizadas
8. Procedimientos operativos
8.1. Reinicio de servicios 8.2. Revisión de logs 8.3. Copia de seguridad de la base de datos 8.4. Restauración básica 8.5. Comprobaciones de estado
9. Incidencias frecuentes
9.1. Error de conexión a MySQL 9.2. Error 403 o 404 en Apache 9.3. Problemas con permisos de archivos 9.4. Fallos al cargar estilos o scripts 9.5. Errores comunes y solución
10. Mejoras futuras
10.1. Autenticación de usuarios 10.2. Panel de administración 10.3. Exportación de incidencias 10.4. Sistema de avisos por correo
11. Conclusiones
11.1. Resultado obtenido 11.2. Valor del sistema 11.3. Posibles ampliaciones
En el módulo anterior vimos qué es la documentación técnica, por qué es importante y qué tipos de documentación existen en informática. Ahora toca dar un paso más: entender qué hace que una documentación sea realmente buena.
Porque no basta con documentar. También hay que documentar bien.
En este módulo el alumno aprenderá cuáles son los principios que convierten un documento técnico en algo útil, claro y profesional. También verá errores muy frecuentes al redactar documentación y aprenderá a detectarlos y corregirlos.
En esta unidad se trabajará:
claridad
precisión
estructura
consistencia
legibilidad
errores comunes al redactar documentos técnicos
¿Qué significa documentar bien?
Documentar bien significa crear un documento que otra persona pueda leer y usar sin perder tiempo, sin interpretar cosas ambiguas y sin tener que preguntarle constantemente al autor.
Una buena documentación técnica debe ayudar a responder preguntas como estas:
¿qué es esto?
¿para qué sirve?
¿cómo se instala?
¿cómo se usa?
¿qué pasos hay que seguir?
¿qué requisitos tiene?
¿cómo sé si funciona?
¿qué hago si falla?
Si el documento no ayuda a responder este tipo de preguntas, entonces probablemente está incompleto o mal planteado.
Idea clave del módulo
Una documentación técnica no se valora por lo mucho que ocupa, sino por lo útil que resulta.
1. Claridad
La claridad es uno de los pilares más importantes de cualquier documentación técnica.
Un documento claro permite que el lector entienda rápido lo que se le está explicando. No obliga a releer varias veces una frase ni a deducir lo que el autor quería decir.
Una documentación clara:
usa frases directas
evita rodeos innecesarios
explica cada paso de forma comprensible
separa bien las ideas
no mezcla demasiadas cosas en el mismo apartado
Ejemplo poco claro
Aquí habría que configurar el servidor para que funcione correctamente según lo que se necesite.
Ejemplo más claro
Edita el archivo de configuración de Apache y cambia el puerto de escucha a 8080. Después reinicia el servicio con systemctl restart apache2.
En el segundo caso, el lector sabe exactamente qué hacer.
2. Precisión
La claridad no basta si el documento no es preciso.
La precisión consiste en explicar las cosas de forma concreta, exacta y verificable.
Una documentación precisa:
indica rutas reales
usa nombres correctos
menciona versiones cuando importa
diferencia comandos parecidos
evita expresiones vagas como “lo normal”, “más o menos”, “si hace falta”, “como siempre”
Ejemplo impreciso
Instala la base de datos y configura el usuario.
Ejemplo preciso
Instala MySQL Server, crea la base de datos inventario, y después crea el usuario appuser con permisos sobre esa base de datos.
La segunda versión reduce dudas y mejora la reproducibilidad.
3. Estructura
Muchas veces un documento falla no porque su contenido sea malo, sino porque está mal organizado.
Un texto técnico necesita una estructura lógica. El lector debe saber dónde empieza una idea, dónde están los pasos, dónde están los requisitos y dónde están los problemas frecuentes.
Una buena estructura suele separar:
introducción o contexto
objetivo
requisitos previos
pasos a realizar
validación
errores frecuentes
conclusiones o siguientes pasos
Problema muy común
Hay documentación donde se mezclan:
teoría
comandos
capturas
opiniones
errores
resultados
…todo ello sin ningún orden.
Eso hace que el lector tenga que “buscar” la información en lugar de encontrarla de forma natural.
Ejemplo de estructura básica útil
1. Objetivo
Qué se va a hacer.
2. Requisitos previos
Qué hace falta antes de empezar.
3. Procedimiento
Pasos ordenados.
4. Validación
Cómo comprobar que ha salido bien.
5. Problemas frecuentes
Qué errores pueden aparecer.
6. Resultado final
Qué se ha conseguido.
4. Consistencia
La consistencia significa mantener el mismo criterio a lo largo de todo el documento.
Por ejemplo:
usar siempre los mismos nombres para las mismas cosas
no cambiar de estilo en cada apartado
seguir la misma lógica en títulos y subtítulos
mantener el mismo formato para comandos, rutas, tablas y notas
Ejemplo de falta de consistencia
En una parte del documento escribes:
Base de datos
Usuario administrador
Carpeta del proyecto
Y más adelante escribes:
BD
admin
directorio principal
Aunque no parezca grave, este tipo de cambios genera confusión.
También afecta al formato
Por ejemplo, no conviene que en una parte los comandos estén así:
sudo apt update
y más adelante aparezcan mezclados dentro del texto sin destacar, o que unas rutas lleven formato y otras no.
La consistencia da sensación de orden y profesionalidad.
5. Legibilidad
La legibilidad tiene que ver con lo fácil que resulta leer y recorrer el documento.
No solo importa lo que se dice, sino cómo se presenta.
Mejora la legibilidad:
usar títulos claros
crear apartados cortos
usar listas cuando conviene
separar bloques de código
dejar espacio entre secciones
usar tablas si ayudan a resumir
destacar notas importantes
no escribir párrafos gigantescos
Ejemplo de mala legibilidad
Un texto largo, sin subtítulos, con comandos mezclados dentro de frases muy extensas.
Ejemplo de buena legibilidad
Un documento con:
apartados definidos
comandos en bloques
pasos numerados
advertencias visibles
ejemplos separados del texto principal
La legibilidad es especialmente importante en documentación técnica porque muchas veces no se lee de principio a fin: se consulta por partes.
6. Orientación al lector
Una documentación técnica no debe escribirse pensando solo en quien la redacta. Debe escribirse pensando en quien la va a usar.
Eso significa que el documento debe adaptarse al perfil del lector.
No es lo mismo escribir para:
uno mismo
un compañero técnico
un profesor
un cliente
un usuario final
Ejemplo
Si documentas una práctica para alumnos principiantes, probablemente debas incluir:
más contexto
pasos más detallados
explicaciones de comandos
ejemplos visuales
Si documentas para un equipo técnico experto, quizá puedas ser más directo y conciso.
7. Reproducibilidad
Una de las mejores formas de medir la calidad de una documentación técnica es esta:
¿Otra persona podría repetir el proceso con ese documento?
Si la respuesta es no, entonces la documentación no está cumpliendo bien su función.
Para que un documento sea reproducible debe incluir:
requisitos previos
pasos en orden
comandos completos
rutas correctas
parámetros importantes
validación de resultado
contexto mínimo
Ejemplo
No basta con poner:
Configura Apache para el proyecto.
Eso no es reproducible.
Es mejor algo como:
Copia el proyecto a /var/www/html/app.
Edita el archivo de virtual host.
Define DocumentRoot /var/www/html/app.
Activa el sitio.
Reinicia Apache.
Comprueba el acceso desde el navegador.
8. Mantenibilidad
Una buena documentación no debe servir solo hoy. También debe poder mantenerse con cierta facilidad.
Una documentación mantenible:
está bien organizada
tiene secciones reutilizables
se puede actualizar sin rehacerla entera
separa lo estable de lo que cambia mucho
evita repeticiones innecesarias
Ejemplo
Si una versión del software cambia con frecuencia, conviene que la documentación tenga una sección concreta para versiones o requisitos, en lugar de repartir esa información por todo el documento.
Errores comunes al redactar documentación técnica
Ahora vamos a ver algunos de los errores más frecuentes. Esta parte suele ayudar mucho a los alumnos porque les permite reconocer fallos típicos que ellos mismos cometen al empezar.
Error 1. Dar cosas por supuestas
El autor sabe lo que ha hecho y cree que el lector también lo entenderá.
Ejemplo
Configuramos el servicio como siempre y continuamos con la instalación.
Problema: ¿Como siempre según quién? Eso solo lo entiende quien lo escribió.
Error 2. Escribir pasos incompletos
A veces se omiten pasos porque parecen obvios.
Ejemplo
Importa la base de datos y ejecuta la aplicación.
Pero quizá falta indicar:
qué archivo SQL usar
con qué usuario
sobre qué base de datos
en qué orden hacerlo
Error 3. No validar resultados
Muchos alumnos ponen comandos, pero no indican cómo comprobar que funcionó.
Ejemplo
Instala Apache.
Bien, pero falta decir:
cómo comprobar que está activo
qué comando usar
qué respuesta esperar
qué debería verse en navegador
Error 4. Mezclar demasiadas cosas en el mismo apartado
Por ejemplo, juntar en una misma sección:
teoría
comandos
explicación de errores
decisiones de diseño
conclusiones
Esto vuelve la documentación caótica.
Error 5. Usar frases ambiguas
Ejemplos típicos
“configura lo necesario”
“haz los cambios correspondientes”
“instala lo que falte”
“corrige los errores si aparecen”
Este tipo de redacción parece técnica, pero en realidad aporta muy poca información útil.
Error 6. No adaptar el nivel de detalle
A veces la documentación es tan breve que no sirve. Otras veces tiene tanto detalle irrelevante que entorpece la lectura.
Hay que encontrar el nivel adecuado según el público y el objetivo.
Error 7. No diferenciar entre borrador y documentación final
Una lista rápida de notas personales no es lo mismo que una guía lista para entregar o compartir.
Es importante enseñar al alumno que documentar también implica revisar, ordenar y pulir.
Cómo mejorar una mala documentación
Una buena forma de enseñar este módulo es mostrar que mejorar documentación no siempre significa reescribir todo desde cero.
Muchas veces basta con aplicar una revisión guiada.
Preguntas de revisión útiles
Antes de dar un documento por bueno, conviene revisar:
¿se entiende el objetivo?
¿queda claro para quién está escrito?
¿los pasos están ordenados?
¿faltan requisitos previos?
¿hay validación?
¿hay frases ambiguas?
¿se usan siempre los mismos términos?
¿se puede localizar rápido cada parte?
¿otra persona podría repetir el proceso?
Ejemplo práctico: de documentación deficiente a documentación útil
Versión deficiente
Instalamos el servidor, cambiamos unas cosas de configuración y luego metemos la base de datos. Después ya se puede probar el proyecto. Si da error habrá que revisar permisos o la conexión.
Versión mejorada
Instalación del entorno
Instala Apache con el comando:
sudo apt install apache2 -y
Instala MySQL Server:
sudo apt install mysql-server -y
Crea la base de datos proyecto_web:
CREATE DATABASE proyecto_web;
Importa el archivo proyecto_web.sql en esa base de datos.
Copia los archivos del proyecto a:
/var/www/html/proyecto_web
Comprueba en el navegador que la aplicación responde correctamente.
Validación
Verifica que Apache esté activo con:
systemctl status apache2
Comprueba que MySQL esté funcionando:
systemctl status mysql
Aquí ya vemos claridad, estructura, precisión y validación.
Qué debe aprender el alumno en este módulo
Al terminar esta unidad, el alumno debe ser capaz de:
identificar si una documentación es clara o confusa
detectar frases ambiguas o imprecisas
organizar mejor un documento técnico
aplicar criterios de consistencia y legibilidad
redactar pasos reproducibles
revisar una documentación para mejorarla antes de entregarla
Resultado práctico del módulo
El alumno analiza una documentación técnica sencilla, detecta sus fallos y la mejora aplicando principios de claridad, precisión, estructura, consistencia y legibilidad.
Actividad propuesta para el módulo
Actividad: detectar y corregir errores de documentación
Lee este fragmento de documentación:
Se instala el servidor web y luego se configura todo para que funcione con la aplicación. Después se mete la base de datos y se comprueba si va bien. Si falla, revisar lo necesario.
Tareas del alumno
Indica qué problemas tiene este texto.
Señala al menos 5 aspectos que deberían mejorarse.
Reescribe el fragmento para convertirlo en una documentación técnica más útil.
Solución orientativa
Problemas detectados
no indica qué servidor web se instala
no explica qué significa “configurar todo”
no especifica cómo se importa la base de datos
no incluye rutas ni comandos
no explica cómo comprobar que funciona
no concreta qué hacer si falla
Reescritura mejorada
Instalación y configuración básica
Instala Apache:
sudo apt install apache2 -y
Copia la aplicación a la carpeta:
/var/www/html/app_incidencias
Crea la base de datos app_incidencias en MySQL.
Importa el archivo app_incidencias.sql.
Edita el archivo de configuración de la aplicación para introducir:
nombre de la base de datos
usuario
contraseña
host
Abre el navegador y accede a la URL del proyecto para comprobar que carga correctamente.
Validación
comprueba el estado de Apache
verifica la conexión con MySQL
revisa permisos de archivos si la aplicación no carga
Caso de uso inventado para este módulo
Imagina que un alumno ha montado una pequeña aplicación de gestión de tareas en PHP y MySQL. Quiere entregar la práctica, pero su documentación consiste solo en:
una lista de comandos sueltos
una captura de la web funcionando
una frase que dice “la instalación es sencilla”
una mención rápida a la base de datos
Aunque la aplicación funcione, esa documentación no sería suficiente para:
repetir el despliegue
corregir errores
mantener el proyecto
evaluarlo correctamente
entregarlo de forma profesional
El problema no es solo el contenido técnico, sino cómo está explicado.
Ejemplo de índice para un documento bien estructurado
Índice de ejemplo
Introducción
Objetivo del documento
Requisitos previos
Instalación del entorno
Configuración de la base de datos
Despliegue de la aplicación
Validación del funcionamiento
Problemas frecuentes
Conclusión
Este índice ya muestra una secuencia lógica y fácil de seguir.
Ideas clave para recordar
Una buena documentación debe ser clara, precisa y útil.
Si un paso no se puede repetir, la documentación está incompleta.
Escribir mucho no garantiza documentar bien.
Una estructura ordenada facilita muchísimo el trabajo técnico.
La revisión final forma parte de la documentación.
🎧 Resumen en audio del tema Escucha este audio para repasar las ideas y los objetivos principales de este proyecto antes de continuar o al finalizar la lectura.
En muchas ocasiones, cuando trabajamos redes, sistemas, servidores, Raspberry Pi, sensores, monitorización o ciberseguridad, necesitamos montar pequeños laboratorios de prueba. A veces basta con una máquina virtual, otras veces usamos varias Raspberry, un switch, un router, discos duros, sensores, placas Arduino o algún equipo adicional.
El problema es que estos montajes suelen acabar ocupando demasiado espacio sobre la mesa: cables por todas partes, transformadores, regletas, adaptadores, tarjetas microSD, discos externos, pantallas, teclados, routers, switches y placas sueltas.
Por eso he decidido empezar un proyecto personal que iré documentando paso a paso: construir un laboratorio móvil dentro de una maleta, pensado para poder transportarlo, conectarlo rápidamente y usarlo como herramienta de trabajo en diferentes proyectos de ASIR, redes, sistemas y ciberseguridad.
No se trata de una práctica para que la realicen directamente los alumnos, al menos no en esta primera fase. La idea es construir una herramienta propia que después pueda utilizar en clase, en demostraciones, en laboratorios guiados y en proyectos más avanzados.
¿Qué quiero construir?
La idea inicial es montar una maleta rígida en cuyo interior irán fijados diferentes dispositivos de red y computación. Algunos de los elementos que estoy valorando incluir son:
un router o punto de acceso;
un switch de red;
una o varias Raspberry Pi;
una pantalla integrada;
discos SSD o discos duros externos;
alimentación centralizada;
ventilación;
conectores accesibles desde el exterior;
cableado interno ordenado;
posiblemente sensores, Arduino u otros módulos según evolucione el proyecto.
La intención es que todo quede montado de forma fija, ordenada y segura, evitando tener que sacar y conectar cada elemento cada vez que quiera usar el laboratorio.
La maleta funcionaría como una pequeña infraestructura portátil:
Maleta abierta │ ├── Router / punto de acceso ├── Switch ├── Raspberry Pi ├── Almacenamiento ├── Pantalla ├── Alimentación interna └── Conexiones de red y periféricos
¿Para qué puede servir este laboratorio móvil?
Este proyecto puede tener muchas aplicaciones dentro de la enseñanza de informática, especialmente en ciclos como ASIR y en módulos relacionados con redes, sistemas y ciberseguridad.
Algunas ideas de uso son:
montar una pequeña red aislada para pruebas;
crear un entorno de ciberseguridad controlado;
simular una red de empresa;
desplegar servicios en Raspberry Pi;
practicar escaneos de red con herramientas como Nmap;
montar laboratorios con IDS, SIEM o monitorización;
hacer pruebas con sensores y recogida de datos;
crear un pequeño servidor portátil;
trabajar con copias de seguridad y almacenamiento;
enseñar conceptos de segmentación, servicios, puertos y tráfico de red;
documentar instalaciones reales paso a paso.
No quiero que sea simplemente una “caja con aparatos”. La idea es que sea una plataforma didáctica reutilizable.
Objetivos del proyecto
El objetivo principal es construir un laboratorio portátil, funcional y documentado, que pueda utilizarse en diferentes contextos educativos y técnicos.
Objetivos técnicos
Diseñar una maleta con dispositivos montados de forma fija.
Centralizar la alimentación para evitar múltiples transformadores.
Mantener separada la parte de 230 V AC de la parte de baja tensión DC.
Usar fusibles y protecciones para cada línea de alimentación.
Integrar router, switch, Raspberry Pi y almacenamiento.
Preparar ventilación para evitar problemas de temperatura.
Ordenar el cableado interno de forma clara y mantenible.
Dejar el montaje preparado para futuras ampliaciones.
Objetivos didácticos
Mostrar a los alumnos cómo se planifica un proyecto técnico real.
Documentar decisiones, errores y mejoras.
Enseñar buenas prácticas de montaje, seguridad y organización.
Usar el laboratorio como base para prácticas de redes, sistemas y ciberseguridad.
Crear material reutilizable para futuras clases.
Mostrar que la informática no es solo software: también hay infraestructura, electricidad, hardware, montaje y mantenimiento.
Por qué hacerlo dentro de una maleta
Una maleta rígida permite crear un entorno compacto, transportable y relativamente protegido.
Las ventajas principales son:
Ventaja
Explicación
Portabilidad
Se puede llevar de un aula a otra o guardar fácilmente
Orden
Los dispositivos quedan fijados y cableados
Rapidez
Se abre, se conecta y se empieza a trabajar
Protección
Los equipos quedan más protegidos que si estuvieran sueltos
Reutilización
Sirve para muchos proyectos diferentes
Presentación
Visualmente es más atractivo para explicar conceptos
También tiene inconvenientes que hay que tener en cuenta:
Riesgo
Medida prevista
Calor interno
Añadir ventiladores y rejillas
Exceso de cableado
Usar distribución ordenada y etiquetas
Seguridad eléctrica
Separar 230 V y baja tensión
Mantenimiento
Montar los equipos de forma accesible
Ampliaciones futuras
Dejar espacio libre y conectores preparados
Primera fase: definir la arquitectura
Antes de cortar, atornillar o comprar componentes sin control, la primera fase será definir una arquitectura básica.
La idea inicial podría ser algo así:
Entrada 230 V AC │ ├── Enchufe interno para portátil o cargador auxiliar │ └── Fuente 230 V AC → 12 V DC │ ├── Router 12 V ├── Switch 12 V ├── Ventiladores 12 V └── Conversor 12 V → 5 V └── Raspberry Pi
La parte importante aquí es que no todos los dispositivos funcionan al mismo voltaje.
Por ejemplo:
el router puede necesitar 12 V;
el switch puede necesitar 5 V, 9 V o 12 V;
la Raspberry necesita 5 V;
los ventiladores pueden ir a 5 V o 12 V;
un portátil normalmente necesita su propio cargador a 230 V.
Por tanto, una de las primeras tareas será identificar el consumo real de cada equipo.
Alimentación: una de las partes más importantes
Uno de los puntos más delicados del proyecto es la alimentación eléctrica.
La solución más simple sería meter una regleta dentro de la maleta y conectar todos los transformadores originales, pero no es la opción más limpia ni la más eficiente en espacio.
La solución que estoy valorando es usar una fuente central de 12 V y, desde ahí, repartir la alimentación mediante una caja de fusibles y conversores DC-DC.
Un posible esquema sería:
Fuente 12 V │ ├── Fusible 2 A → Router ├── Fusible 2 A → Switch ├── Fusible 3 A → Conversor 12 V a 5 V → Raspberry ├── Fusible 1 A → Ventiladores └── Fusible 1 A → Pantalla o accesorios
Esto permite tener una instalación más ordenada, pero también obliga a hacerlo con cuidado.
No se trata solo de que “funcione”. Tiene que ser seguro, mantenible y comprensible.
Seguridad antes que estética
Aunque el objetivo es que la maleta quede bien presentada, la prioridad será siempre la seguridad.
Algunas normas que quiero seguir desde el principio:
no dejar conexiones de 230 V expuestas;
usar entrada de corriente con interruptor y fusible;
separar físicamente la zona de alta tensión y la zona de baja tensión;
proteger cada línea de 12 V con su fusible;
usar cable de sección adecuada;
evitar cables finos tipo Arduino para alimentar equipos;
comprobar polaridad y voltaje con multímetro antes de conectar nada;
añadir ventilación;
etiquetar cables y conexiones;
documentar cada cambio.
Esto también forma parte del aprendizaje. Muchas veces en clase enseñamos servicios, comandos, configuraciones y herramientas, pero no siempre se ve la parte física de montar una pequeña infraestructura de forma ordenada.
Posibles usos en ciberseguridad
Uno de los motivos principales para construir esta maleta es poder usarla como base para laboratorios de ciberseguridad.
Algunas posibilidades futuras:
1. Laboratorio de escaneo y reconocimiento
Usar la red interna de la maleta para practicar:
descubrimiento de hosts;
escaneo de puertos;
identificación de servicios;
pruebas con Nmap;
análisis de tráfico.
2. Mini SOC educativo
Integrar herramientas como:
Wazuh;
Suricata;
Grafana;
Prometheus;
logs centralizados;
alertas básicas.
3. Red aislada de pruebas
Crear un entorno donde se puedan levantar máquinas vulnerables o servicios de prueba sin afectar a la red real del aula.
4. Servidor portátil
Una Raspberry con almacenamiento podría actuar como:
servidor web;
servidor de ficheros;
servidor de logs;
panel de control;
repositorio local de documentación o scripts.
5. Simulación de red empresarial
Con router, switch y varios nodos se puede representar una pequeña red con:
clientes;
servidores;
segmentos;
servicios internos;
reglas de firewall;
monitorización.
Documentar el proceso: una parte esencial del proyecto
Este proyecto no solo consistirá en montar la maleta. También quiero documentar cada fase.
La documentación incluirá:
materiales utilizados;
decisiones de diseño;
esquemas de conexión;
pruebas realizadas;
problemas encontrados;
soluciones aplicadas;
fotografías del montaje;
configuraciones de red;
scripts utilizados;
posibles mejoras;
conclusiones de cada fase.
La idea es que cualquier persona que siga el proyecto pueda entender no solo el resultado final, sino también el razonamiento detrás de cada decisión.
Porque en proyectos reales rara vez todo sale perfecto a la primera. Hay que medir, probar, corregir, reorganizar y volver a probar.
Fases previstas del proyecto
Aunque el diseño todavía está abierto, una posible planificación inicial sería la siguiente:
Fase
Descripción
Fase 1
Definir objetivos y componentes iniciales
Fase 2
Elegir la maleta y diseñar la distribución interna
Fase 3
Planificar la alimentación eléctrica
Fase 4
Montar fuente, fusibles y distribución de 12 V
Fase 5
Integrar router, switch y Raspberry Pi
Fase 6
Añadir pantalla y almacenamiento
Fase 7
Configurar red interna y servicios básicos
Fase 8
Preparar primeros laboratorios de prueba
Fase 9
Documentar errores, mejoras y ampliaciones
Fase 10
Usar la maleta en proyectos reales de clase
Esta planificación podrá cambiar. De hecho, seguramente cambiará. Y eso también será parte del valor del proyecto.
Qué componentes estoy valorando
Por ahora, la lista de componentes posibles incluye:
Componente
Función
Maleta rígida
Estructura principal
Router
Crear o gestionar la red
Switch
Conectar varios equipos por cable
Raspberry Pi
Nodo principal de servicios
Pantalla
Visualización local
SSD/HDD
Almacenamiento
Fuente 12 V
Alimentación principal
Conversor 12 V a 5 V
Alimentar Raspberry
Caja de fusibles
Proteger líneas DC
Ventiladores
Refrigeración
Conectores de panel
Acceso externo ordenado
Cableado etiquetado
Mantenimiento
Interruptores
Control de encendido
Voltímetro/amperímetro
Supervisión de consumo
No todos tienen por qué estar desde el primer día. La idea es empezar con una base sencilla y hacerla crecer.
Qué quiero conseguir al final
Al terminar el proyecto me gustaría tener una herramienta que pueda abrir en clase y utilizar directamente.
Algo parecido a esto:
Abrir maleta │ ├── Conectar alimentación ├── Encender router/switch/Raspberry ├── Levantar servicios ├── Conectar portátil ├── Acceder al panel o terminal └── Empezar la práctica
Un laboratorio listo para trabajar.
No sustituirá a Proxmox, VirtualBox, Docker o las máquinas virtuales, pero sí puede complementarlas muy bien. Aporta algo físico, visible y tangible, que ayuda mucho cuando se explican redes, sistemas y seguridad.
Por qué merece la pena documentarlo
Este tipo de proyectos tienen un valor especial porque mezclan muchas áreas:
hardware;
redes;
sistemas;
electricidad básica;
Linux;
documentación;
seguridad;
automatización;
diseño;
resolución de problemas.
Es exactamente el tipo de proyecto que permite enseñar que la informática real no está formada por piezas aisladas. Todo se conecta con todo.
Un router no es solo un aparato con antenas. Una Raspberry no es solo una placa pequeña. Un switch no es solo una caja con puertos. Una fuente de alimentación no es un detalle secundario. Y una buena documentación no es un trámite: es lo que permite entender, mantener y mejorar el sistema.
Próximos pasos
En las siguientes entradas iré publicando el avance del proyecto.
Algunos de los próximos temas serán:
elección de la maleta;
diseño de la distribución interna;
elección de la fuente de alimentación;
montaje de la caja de fusibles;
conexión del router y el switch;
alimentación de la Raspberry;
integración de pantalla;
montaje del almacenamiento;
ventilación;
primeras pruebas de red;
primeras prácticas de ciberseguridad.
La idea es que este artículo sea el punto de partida de una serie. No quiero presentar solo el resultado final, sino todo el camino.
Conclusión
Este proyecto nace de una necesidad muy concreta: disponer de un laboratorio móvil, compacto y reutilizable para trabajar redes, sistemas y ciberseguridad de una forma más práctica y visual.
Todavía está en construcción. Algunas decisiones cambiarán, aparecerán problemas y seguramente habrá que rediseñar partes del montaje. Pero precisamente eso es lo interesante: convertir el proceso en aprendizaje.
A partir de aquí comienza la construcción del Laboratorio Móvil de Ciberseguridad.
Un proyecto para aprender, probar, equivocarse, mejorar y, sobre todo, llevar la práctica técnica un paso más allá.
Especificaciones para Montaje de Maleta-Laboratorio Electrónica
Elemento
Categoría
Voltaje Requerido
Amperaje/Potencia
Cantidad
Función
Fuente de alimentación AC/DC (Kingwen o similar)
Alimentación DC
Entrada: 230 V AC
12 V DC / 10 A – 20 A (120 W – 240 W)
1
Fuente principal para alimentar los dispositivos internos
Raspberry Pi 4/5
Cómputo
5 V DC
3 A – 5 A (15 W – 25 W)
Según diseño
Nodo de computación principal
Router
Red
12 V DC (típico)
1 A – 2 A
1
Gestión de red y conectividad
Switch Gigabit
Red
12 V DC (o 9 V / 5 V)
0.6 A – 1 A
1
Interconexión de los dispositivos de red
Conversor DC-DC Buck
Alimentación DC
Entrada: 12 V / Salida: 5 V
3 A – 5 A
1 por Raspberry
Reducir el voltaje de 12 V a 5 V para alimentar la Raspberry Pi
Caja de fusibles DC (Blade)
Seguridad
12 V DC
Soporte multi-vía
1
Protección individual de líneas (2 A para router, 3 A para RPi)
Entrada IEC C14 con interruptor y fusible
Alimentación AC
230 V AC
Protección por fusible
1
Punto de entrada único de corriente exterior para la maleta
Enchufe AC schuko / panel
Alimentación AC
230 V AC
Según cargador de portátil
1
Conexión interna para un ordenador portátil
Barra de distribución (Negativos)
Alimentación DC
12 V DC
Según carga total
1
Organización de los retornos de masa y negativos
Cable eléctrico flexible 1.5 mm2 – 2.5 mm2
Cableado
12 V DC
Línea principal
Varios metros
Cableado de alimentación desde la fuente a la distribución (evita caídas de tensión)
Cable eléctrico flexible 0.75 mm2
Cableado
12 V DC
Líneas de dispositivos
Varios metros
Conexión secundaria para router, switch y conversores
Cable 3 x 1.5 mm2 homologado
Cableado
230 V AC
Alta tensión
Varios metros
Conexión segura de entrada IEC y enchufe para portátil
Ventiladores 12 V
Climatización
12 V DC
2 W – 5 W
1 o 2
Extracción de calor y ventilación forzada para evitar sobrecalentamientos
Maleta rígida
Estructura
N/A
N/A
1
Carcasa y base del montaje del laboratorio
Placa interior de montaje
Estructura
N/A
N/A
1
Superficie para el anclaje y atornillado de todos los componentes
🎧 Resumen en audio del tema Escucha este audio para repasar las ideas y los objetivos principales de este proyecto antes de continuar o al finalizar la lectura.
En la primera parte del proyecto presenté la idea general: construir un laboratorio móvil dentro de una maleta, pensado para usarlo en clases, demostraciones y prácticas relacionadas con ASIR, redes, sistemas y ciberseguridad.
La idea no es construir un simple maletín con aparatos dentro, sino una pequeña plataforma técnica, transportable y reutilizable, que pueda servir para diferentes escenarios:
prácticas de redes;
laboratorios de ciberseguridad;
pruebas con Raspberry Pi;
despliegue de servicios;
análisis de tráfico;
monitorización;
almacenamiento;
automatización;
simulación de infraestructuras pequeñas.
Una vez planteada la idea general, llega una de las partes más importantes y, al mismo tiempo, una de las más complicadas para mí: cómo sujetar todos los elementos dentro de la maleta de forma ordenada, segura y modificable.
Podría utilizar madera, metacrilato, impresión 3D, piezas metálicas o soportes hechos a medida, pero en mi caso hay un condicionante importante: no tengo grandes conocimientos de carpintería, trabajo con plásticos o fabricación de piezas. Tampoco quiero que el proyecto se bloquee porque necesite herramientas especiales o un acabado perfecto desde el principio.
Por eso he decidido usar una solución más sencilla, modular y muy flexible: LEGO Technic.
La idea principal
La idea es forrar el fondo de la maleta, y posiblemente también la tapa, con planchas base compatibles con LEGO. Sobre esas planchas iré construyendo estructuras con piezas LEGO Technic para sujetar los componentes, ordenar los cables y crear diferentes niveles o “pisos”.
De esta forma, en lugar de tener que cortar, taladrar y fabricar piezas a medida desde el primer día, podré ir probando distribuciones y modificarlas fácilmente.
La estructura inicial podría dividirse en dos zonas:
TAPA DE LA MALETA │ ├── Pantalla ├── Router o punto de acceso ├── Switch ├── Panel de conexiones └── Guiado de cables
FONDO DE LA MALETA │ ├── Fuente de alimentación ├── Caja de fusibles ├── Conversores DC-DC ├── Raspberry Pi ├── SSD / HDD ├── Hub USB └── Canalización de cables
No busco que el primer diseño sea definitivo. De hecho, lo más probable es que vaya cambiando. Y precisamente esa es una de las razones por las que LEGO Technic puede funcionar muy bien en este proyecto.
Prototipo generado con IA
¿Por qué usar LEGO Technic?
A primera vista puede parecer una solución poco profesional, incluso algo improvisada. Sin embargo, para este tipo de proyecto tiene bastante sentido.
LEGO Technic permite crear estructuras resistentes, desmontables y ajustables. Sus vigas perforadas, conectores, ejes y pines permiten montar soportes, marcos, guías y separadores sin tener que fabricar piezas desde cero.
Además, este proyecto tiene una parte claramente educativa. Usar LEGO Technic permite que el montaje sea más visual y fácil de entender. Los alumnos podrán ver claramente cómo están organizados los elementos, cómo se separan las zonas y cómo se puede rediseñar una estructura cuando algo no funciona como esperábamos.
No se trata de usar LEGO como un juguete, sino como una herramienta de prototipado.
Ventajas de esta solución
Usar LEGO Technic puede aportar varias ventajas importantes:
Ventaja
Explicación
Modularidad
Permite cambiar la distribución sin rehacer todo el montaje
Accesibilidad
No requiere herramientas complejas
Reutilización
Las piezas se pueden desmontar y volver a usar
Rapidez
Se pueden probar ideas de forma muy ágil
Diseño por niveles
Permite crear pisos y soportes elevados
Organización
Facilita guiar cables y separar zonas
Visual
Ayuda a explicar el diseño a los alumnos
Didáctico
Muestra el proceso de prototipado y mejora continua
Una de las grandes ventajas es que no necesito acertar con el diseño a la primera. Puedo montar una primera versión, comprobar si cabe todo, ver si los cables llegan bien, probar la ventilación y después modificar lo necesario.
Límites de esta solución
También hay que ser realista. LEGO Technic no sirve para todo.
No debe utilizarse como soporte principal de elementos peligrosos, pesados o que puedan calentarse mucho. Tampoco debe usarse como protección eléctrica para la zona de 230 V.
Esto es importante:
LEGO Technic puede servir para ordenar, separar, elevar y sujetar elementos ligeros, pero no debe ser la base de la seguridad eléctrica del proyecto.
Por tanto, usaré LEGO principalmente para:
crear soportes;
elevar placas;
guiar cables;
hacer marcos;
crear pisos;
organizar zonas;
facilitar el desmontaje;
mejorar la presentación visual.
Pero evitaré depender solo de LEGO para:
sujetar la fuente de alimentación si pesa bastante;
proteger conexiones de 230 V;
fijar elementos que soporten tirones;
sujetar discos duros mecánicos sin apoyo adicional;
colocar piezas junto a zonas con mucho calor;
soportar elementos que puedan moverse durante el transporte.
Para estos casos, usaré refuerzos adicionales: tornillos, bridas, velcro industrial, separadores, soportes metálicos o piezas específicas.
Prototipo Generado con IA
Diseño general de la maleta
La maleta que voy a utilizar es más parecida a una maleta rígida de aluminio o herramientas que a una maleta tipo militar o Pelican. Esto condiciona bastante el diseño.
Este tipo de maleta suele tener:
fondo relativamente plano;
tapa con cierta profundidad;
paredes interiores no demasiado gruesas;
bisagras metálicas;
cierres frontales;
asa de transporte;
interior acolchado o revestido.
La idea será aprovechar tanto el fondo como la tapa.
Prototipo generado con IA
Fondo de la maleta
En el fondo colocaré los elementos que necesitan mayor estabilidad o que pesan más:
fuente de alimentación;
caja de fusibles;
distribución de 12 V;
conversores de voltaje;
Raspberry Pi;
discos SSD o HDD;
hub USB;
cableado principal.
El fondo será la zona principal de trabajo técnico. Aquí estará la mayor parte de la electrónica y la distribución de alimentación.
Una posible distribución inicial sería:
FONDO DE LA MALETA
┌──────────────────────────────────────────────┐ │ Fuente 12 V Caja de fusibles │ │ │ │ Conversores DC Raspberry Pi │ │ │ │ SSD / HDD Hub USB │ │ │ │ Zona libre para futuras ampliaciones │ └──────────────────────────────────────────────┘
Tapa de la maleta
En la tapa quiero colocar elementos más visibles o de acceso rápido:
pantalla;
router o punto de acceso;
switch;
posiblemente algún panel de conectores;
guías para cables Ethernet;
indicadores visuales;
etiquetas o esquema del sistema.
La tapa puede quedar muy bien para la parte más demostrativa del proyecto. Al abrir la maleta, lo primero que se verá será la pantalla, el router, el switch y las conexiones principales.
Aunque use LEGO Technic para organizar el montaje, no todo debe mezclarse en el mismo espacio. Una de las primeras decisiones será dividir la maleta en varias zonas funcionales.
Zona 1: alimentación de 230 V AC
Esta es la zona más delicada.
Aquí estarán:
entrada IEC de corriente;
interruptor general;
fusible de entrada;
enchufe interno para portátil, si finalmente lo incluyo;
entrada de la fuente de alimentación de 12 V.
Esta zona debe ir protegida, aislada y separada del resto.
No debe haber bornes expuestos ni cables sueltos de 230 V. Si incluyo un enchufe interno, debe ser un módulo fijo, correctamente sujeto y protegido.
Esta zona no debería depender de LEGO como protección principal.
ZONA 230 V AC
Entrada IEC │ ├── Enchufe interno para portátil │ └── Fuente AC/DC 12 V
Zona 2: distribución de 12 V DC
Desde la fuente de alimentación saldrá una línea de 12 V DC que irá a una caja de fusibles.
Aquí se repartirán las salidas hacia:
router;
switch;
ventiladores;
conversor 12 V a 5 V para Raspberry;
pantalla, si usa 12 V;
otros módulos.
Fuente 12 V │ └── Caja de fusibles │ ├── Router ├── Switch ├── Conversor Raspberry ├── Ventiladores └── Extras
Esta parte ya es de baja tensión, pero aun así debe estar bien ordenada y protegida.
Zona 3: computación y almacenamiento
Aquí estarán los elementos que ejecutarán servicios o almacenarán datos:
Raspberry Pi;
SSD;
disco duro;
hub USB;
posibles adaptadores;
tarjeta microSD accesible;
cables USB;
cable HDMI si se usa pantalla.
Esta zona debe estar ventilada y permitir acceso a puertos.
Zona 4: red
La zona de red incluirá:
router;
switch;
latiguillos Ethernet;
posibles puertos externos RJ45;
conexión con la Raspberry;
conexión con el portátil.
La idea es que la red sea clara y fácil de explicar.
Por ejemplo:
Router / AP │ └── Switch │ ├── Raspberry Pi ├── Puerto externo 1 ├── Puerto externo 2 └── Portátil del profesor
Montaje con planchas LEGO
El primer paso físico será colocar planchas base en la maleta.
Estas planchas funcionarán como una superficie modular sobre la que podré fijar estructuras.
Opciones de fijación
Para fijar las planchas a la maleta puedo usar varias opciones:
Sistema
Ventaja
Inconveniente
Cinta de doble cara fuerte
Fácil y rápida
Puede despegarse con calor
Velcro industrial
Desmontable
Añade grosor
Tornillos pequeños
Muy firme
Hay que taladrar
Adhesivo de montaje
Fuerte
Difícil de retirar
Bridas
Reversible si hay puntos de paso
Depende de la maleta
Mi idea inicial sería usar velcro industrial o una fijación que permita retirar las planchas si el diseño cambia.
No quiero hacer un pegado definitivo demasiado pronto. El proyecto todavía está en fase de diseño y seguramente habrá modificaciones.
Fondo con planchas LEGO
En el fondo colocaría una o varias planchas ajustadas al tamaño de la maleta.
Sobre ellas se podrán montar:
soportes para Raspberry;
bases para SSD;
guías de cableado;
zonas elevadas;
topes laterales;
estructuras de separación.
Ejemplo:
Base de la maleta │ ├── Velcro industrial │ ├── Plancha LEGO │ ├── Estructura Technic │ └── Dispositivos
Tapa con planchas LEGO
La tapa es más delicada porque todo lo que se coloque ahí estará en vertical cuando la maleta esté abierta.
Para la tapa, usaría LEGO Technic solo con elementos ligeros o bien reforzados.
Podrían ir ahí:
pantalla ligera;
router pequeño;
switch pequeño;
guías de cables;
soportes visuales;
etiquetas.
Si algún elemento pesa mucho, no confiaría solo en LEGO. Usaría tornillos, bridas o velcro industrial adicional.
Soportes para componentes
Cada componente necesita una solución distinta. No es lo mismo sujetar una Raspberry que un router o un disco duro.
Soporte para Raspberry Pi
La Raspberry Pi no debería ir directamente apoyada sobre la base.
La colocaría elevada con separadores para que:
no toque superficies;
circule aire por debajo;
los puertos queden accesibles;
se pueda desmontar;
no haya riesgo de cortocircuito.
La estructura podría ser:
Raspberry Pi │ ├── Tornillos M2.5 ├── Separadores de nylon ├── Plataforma LEGO Technic └── Base LEGO
Lo ideal sería usar los agujeros de montaje de la Raspberry con tornillos M2.5 y separadores de nylon.
LEGO puede servir como plataforma, pero la placa debería ir fijada con tornillos adecuados, no simplemente encajada a presión.
Soporte para router
El router puede colocarse de varias formas.
Opción 1: marco lateral
Crear un marco Technic que impida que se desplace.
Si el switch va en la tapa, reforzaría la sujeción con velcro o bridas.
Soporte para SSD
Un SSD pesa poco y no genera demasiado calor, por lo que puede fijarse bastante bien.
Opciones:
velcro industrial;
marco LEGO;
bridas suaves;
soporte elevado.
Si uso un SSD externo por USB, me interesa que pueda retirarse fácilmente. En ese caso usaría velcro o un marco desmontable.
Soporte para disco duro mecánico
Si uso un HDD mecánico, tendría más cuidado.
Un disco mecánico es más sensible a golpes y vibraciones. Además pesa más que un SSD.
Para un HDD usaría:
base acolchada;
sujeción con velcro fuerte;
topes laterales;
posición estable en el fondo, no en la tapa;
evitar que quede colgando;
evitar golpes durante el transporte.
Sinceramente, para este proyecto me parece más adecuado usar SSD que HDD mecánico.
Soporte para pantalla
La pantalla probablemente será uno de los elementos más visibles.
Si va en la tapa, hay que tener en cuenta:
peso;
grosor;
alimentación;
cable HDMI o USB;
ángulo de visión;
protección al cerrar la maleta;
posibilidad de golpes.
La pantalla debería ir en un soporte más robusto que el resto. LEGO puede ayudar a posicionarla, pero seguramente convenga reforzarla con velcro industrial, tornillos o una pieza rígida adicional.
Una posible solución:
Tapa de la maleta │ ├── Plancha base ├── Marco Technic ├── Velcro industrial └── Pantalla
También hay que dejar espacio para que al cerrar la maleta la pantalla no choque con los elementos del fondo.
Diseño por niveles
Prototipo generado con IA
Una de las mejores ventajas de LEGO Technic es que permite crear estructuras por niveles.
Esto puede ayudar mucho en una maleta donde el espacio es limitado.
Nivel inferior
En el nivel inferior podría ir:
cableado principal;
conversores DC-DC;
distribución de 12 V;
ventiladores pequeños;
canalización.
Nivel intermedio
En el nivel intermedio:
Raspberry Pi;
SSD;
hub USB;
módulos auxiliares.
Nivel superior
En el nivel superior:
router;
switch;
pantalla;
conectores accesibles.
Un ejemplo:
NIVEL 3: Pantalla / Router / Switch ─────────────────────────────────── NIVEL 2: Raspberry / SSD / Hub ─────────────────────────────────── NIVEL 1: Fuente / Fusibles / Conversores ─────────────────────────────────── BASE LEGO
Este diseño permite esconder algunos cables por debajo y dejar visibles los elementos que interesa enseñar.
Pero hay que tener cuidado: demasiados niveles pueden complicar el mantenimiento.
La regla debería ser:
Todo componente importante debe poder desmontarse sin tener que desmontar media maleta.
Organización de cables
El cableado será una de las partes más importantes del proyecto.
Una maleta de laboratorio puede quedar muy atractiva por fuera, pero si por dentro los cables están desordenados, será difícil de mantener y de explicar.
LEGO Technic puede ayudar mucho a crear guías, canales y separadores.
Tipos de cableado
Dentro de la maleta habrá varios tipos de cables:
Tipo de cable
Uso
230 V AC
Entrada de corriente y enchufe interno
12 V DC
Router, switch, ventiladores, conversores
5 V DC
Raspberry y algunos módulos
Ethernet
Red entre router, switch y Raspberry
USB
SSD, hub, periféricos
HDMI
Pantalla
Sensores
Señales de baja corriente
Estos cables no deberían ir mezclados sin criterio.
Separación recomendada
Una buena organización podría ser:
Lateral izquierdo: - Alimentación DC
Zona central: - Raspberry / SSD / hub
Lateral derecho: - Ethernet
Zona aislada: - 230 V AC
O también:
Parte inferior: - Alimentación
Parte superior: - Red
Centro: - Computación
Lo importante no es la distribución exacta, sino que sea coherente y documentada.
Colores recomendados
Usar colores ayuda mucho.
Cable
Color recomendado
12 V positivo
Rojo
12 V negativo
Negro
5 V positivo
Rojo
5 V negativo
Negro
Ethernet
Azul
USB
Negro
HDMI
Negro
Señales/sensores
Amarillo, verde o blanco
230 V AC
Cable homologado, claramente separado
No siempre se podrá elegir el color de todos los cables, pero sí podemos etiquetarlos.
Otra idea es crear pequeños “puentes” para que los cables pasen por debajo de un nivel superior sin quedar aplastados.
Nivel superior ────────────── Cable pasa por debajo ════════════════════════ Base LEGO
Sujeción durante el transporte
No basta con que los componentes queden bien cuando la maleta está abierta sobre una mesa. También deben aguantar el transporte.
Durante el transporte pueden aparecer:
vibraciones;
golpes;
movimientos laterales;
cables que tiran;
conectores que se aflojan;
piezas que se sueltan.
Por eso, cada elemento debería superar una prueba básica:
Si muevo suavemente la maleta cerrada, nada importante debería desplazarse.
Para eso usaré una combinación de:
topes LEGO;
bridas;
velcro industrial;
tornillos;
separadores;
espumas protectoras si hace falta.
Cuidado con la tapa
Los elementos montados en la tapa tienen más riesgo de moverse o caer.
Por tanto, en la tapa usaré preferentemente:
piezas ligeras;
elementos bien fijados;
cableado con holgura;
soportes reforzados;
nada que pueda caer sobre la Raspberry o la fuente.
Si coloco la pantalla en la tapa, tendrá que ir especialmente bien sujeta.
Ventilación
La ventilación será otro punto clave.
Dentro de la maleta habrá elementos que generan calor:
fuente de alimentación;
Raspberry Pi;
router;
switch;
conversores DC-DC;
discos;
pantalla.
Una maleta cerrada no es una caja ideal para electrónica. Por eso habrá que prever circulación de aire.
Posible diseño de ventilación
Una opción sencilla:
Entrada de aire frío ─────► interior ─────► salida de aire caliente rejilla ventilador
Colocaría al menos:
una rejilla de entrada;
una rejilla de salida;
un ventilador de 12 V;
filtro antipolvo si es posible.
El ventilador puede alimentarse desde la línea de 12 V con su propio fusible.
LEGO y calor
LEGO es plástico. No debe estar pegado a elementos que se calienten mucho.
Hay que evitar colocar piezas LEGO justo encima o pegadas a:
disipadores;
fuente de alimentación;
zonas de ventilación;
reguladores de voltaje;
routers calientes;
pantalla si se calienta por detrás.
La regla es simple:
LEGO puede organizar la estructura, pero el calor necesita espacio.
Seguridad eléctrica
Esta parte no se puede tomar a la ligera.
Aunque la mayoría del montaje funcione a 12 V o 5 V, habrá una entrada de 230 V AC. Además, si incluyo un enchufe interno para conectar un portátil, habrá una derivación de red dentro de la maleta.
Normas básicas que seguiré
La zona de 230 V irá separada del resto.
No habrá bornes de 230 V expuestos.
La entrada de corriente tendrá fusible e interruptor.
El enchufe interno irá fijo, no suelto.
La fuente de alimentación irá bien anclada.
Se usará cable adecuado para 230 V.
La tierra se conectará correctamente cuando corresponda.
La parte DC tendrá fusibles por línea.
Antes de conectar equipos, se medirá voltaje y polaridad.
No se usarán cables Dupont o de Arduino para alimentación de potencia.
Lo que no haré
No quiero que el proyecto acabe en una chapuza peligrosa. Por tanto, evitaré:
regletas sueltas dentro de la maleta;
empalmes sin protección;
230 V pasando junto a cables de señal;
fuentes sin ventilación;
cables finos para alimentar Raspberry;
dispositivos sin fusible;
conectores sin etiquetar;
piezas móviles que puedan tocar bornes;
cerrar la maleta con elementos presionando cables.
Cable adecuado
El cable típico de Arduino sirve para señales y sensores, pero no para alimentar la maleta.
Para este montaje usaré cables de sección adecuada.
Tramo
Cable recomendado
230 V AC
Cable homologado 3 x 1,5 mm²
Fuente 12 V a caja de fusibles
1,5 mm² o 2,5 mm²
Caja de fusibles a router
0,75 mm²
Caja de fusibles a switch
0,75 mm²
Caja de fusibles a conversor Raspberry
0,75 mm² o 1 mm²
Ventiladores
0,5 mm² o 0,75 mm²
Sensores
Cable fino tipo Arduino, solo para señal
La Raspberry es especialmente sensible a las caídas de tensión. Por eso el tramo de 5 V debe ser corto y de buena calidad.
Alimentación prevista
El diseño de alimentación inicial será algo parecido a esto:
Entrada 230 V AC │ ├── Enchufe interno para portátil │ └── Fuente 230 V AC → 12 V DC │ └── Caja de fusibles 12 V │ ├── Router 12 V / 1 A ├── Switch 12 V / 1 A ├── Conversor 12 V → 5 V → Raspberry ├── Ventiladores 12 V └── Extras
Cada línea tendrá su propio fusible.
Valores orientativos:
Línea
Fusible orientativo
Router 12 V / 1 A
2 A
Switch 12 V / 1 A
2 A
Conversor Raspberry
3 A
Ventiladores
1 A
LED / voltímetro
1 A
Estos valores podrán ajustarse en función de los consumos reales.
Documentación del proceso
Una parte fundamental del proyecto será documentar todo el proceso.
No quiero limitarme a enseñar la maleta terminada. Quiero enseñar cómo se ha ido construyendo, qué decisiones se han tomado, qué errores han aparecido y qué cambios han sido necesarios.
Esta segunda fase se presta mucho a documentación visual.
Fotografías que quiero hacer
Durante esta fase documentaré:
la maleta vacía;
las planchas LEGO antes de colocarlas;
primera prueba de distribución;
colocación provisional de router, switch y Raspberry;
soporte de la Raspberry;
soporte del switch;
soporte del router;
zona de alimentación;
caja de fusibles;
guías de cableado;
prueba de cierre de la maleta;
primera versión completa sin alimentar;
modificaciones después de detectar problemas.
Qué explicar en cada foto
Cada foto debería ir acompañada de una explicación breve:
qué se está probando;
por qué se ha colocado ahí;
qué problema resuelve;
qué inconvenientes tiene;
qué habría que mejorar;
si es una solución provisional o definitiva.
Esto es muy importante porque convierte el proyecto en una experiencia de aprendizaje, no solo en una galería de fotos.
Propuesta de fases para esta segunda parte
Para no convertir el montaje en un caos, dividiré esta fase en varias iteraciones.
Iteración 1: distribución sin fijar nada
Primero colocaré todos los componentes dentro de la maleta sin fijarlos.
Objetivo:
comprobar si caben;
ver si la tapa cierra;
observar accesos a puertos;
detectar zonas conflictivas;
decidir qué va en el fondo y qué va en la tapa.
Preguntas que quiero responder:
¿Cabe todo? ¿La maleta cierra? ¿Hay espacio para cables? ¿Se puede acceder a los puertos? ¿Dónde irá la ventilación? ¿Dónde irá la zona de 230 V?
Iteración 2: colocación de planchas LEGO
Después colocaré las planchas base.
Primero intentaré hacerlo de forma reversible, probablemente con velcro industrial o un sistema que pueda modificar.
Objetivo:
crear una superficie modular;
comprobar si las piezas encajan bien;
decidir si hace falta recortar o ajustar;
ver si el grosor añadido afecta al cierre.
Iteración 3: soportes provisionales
Construiré soportes iniciales para:
Raspberry Pi;
router;
switch;
SSD;
caja de fusibles;
conversores.
En esta fase no me preocuparé demasiado por el acabado final. Lo importante será validar el diseño.
Iteración 4: rutas de cableado
Antes de conectar nada definitivamente, diseñaré los caminos de los cables.
Separaré:
alimentación;
red;
USB;
HDMI;
sensores;
230 V.
Objetivo:
evitar cruces innecesarios;
dejar holgura;
no forzar conectores;
permitir desmontaje;
mejorar la limpieza visual.
Iteración 5: prueba de cierre
Con todos los elementos colocados, cerraré la maleta sin alimentar nada.
Esta prueba es fundamental.
Hay que comprobar:
si la pantalla choca con algo;
si los cables se aplastan;
si la Raspberry queda presionada;
si el router o switch tocan la tapa;
si algún conector queda forzado;
si los soportes aguantan.
Iteración 6: cableado de baja tensión
Después empezaré con la parte de 12 V y 5 V.
Primero sin conectar los dispositivos finales. Mediré con multímetro:
salida de la fuente;
polaridad;
salida de cada fusible;
salida del conversor 12 V a 5 V.
Solo después conectaré router, switch y Raspberry.
Iteración 7: pruebas de funcionamiento
Una vez alimentados los equipos, comprobaré:
arranque de la Raspberry;
funcionamiento del router;
funcionamiento del switch;
conexión de red;
acceso desde portátil;
temperatura después de un rato;
estabilidad de alimentación;
posibles reinicios o fallos.
Iteración 8: acabado y etiquetado
Cuando todo funcione, llegará el momento de ordenar y etiquetar.
Añadiré:
etiquetas en cables;
etiquetas en fusibles;
etiquetas en conectores;
indicaciones de voltaje;
esquema interno;
versión del montaje.
Me gustaría que al abrir la maleta se pueda entender qué es cada cosa.
Materiales previstos para esta fase
Una lista inicial de materiales podría ser:
Material
Uso
Planchas base LEGO o compatibles
Forrar fondo y tapa
Vigas LEGO Technic
Estructuras y soportes
Pines Technic
Uniones desmontables
Ejes Technic
Refuerzo
Escuadras Technic
Soportes en ángulo
Bricks básicos
Topes y separadores
Velcro industrial
Sujeción desmontable
Bridas pequeñas
Sujeción de cables
Bridas reutilizables
Pruebas y prototipado
Separadores de nylon
Elevar Raspberry y placas
Tornillos M2.5 / M3
Fijar placas
Etiquetas adhesivas
Identificación
Canaleta pequeña
Guiado opcional de cables
Cinta de doble cara fuerte
Fijación auxiliar
Gomas o espuma fina
Protección antivibración
Herramientas necesarias
No quiero que esta fase dependa de herramientas complejas.
Probablemente usaré:
Herramienta
Uso
Destornilladores pequeños
Tornillos y soportes
Alicates de corte
Cortar bridas
Multímetro
Medir voltajes
Cúter
Ajustes ligeros
Regla o metro
Medir distribución
Rotulador
Marcas provisionales
Crimpadora
Terminales eléctricos
Pelacables
Preparar cableado
Taladro pequeño
Solo si finalmente fijo algo con tornillos
La idea es mantener el montaje dentro de algo asumible y replicable.
Riesgos y problemas esperados
Es importante anticipar problemas.
1. Que las piezas se suelten
LEGO encaja bien, pero si la maleta se mueve mucho, algunas piezas podrían soltarse.
Solución:
reforzar estructuras;
usar bridas;
usar velcro;
no depender de una sola unión;
probar transporte antes de darlo por válido.
2. Que la tapa no cierre
Al añadir niveles, cables y soportes, puede que la maleta deje de cerrar correctamente.
Solución:
hacer pruebas frecuentes de cierre;
no esperar al final;
dejar margen de altura;
evitar cables cruzando por zonas de presión.
3. Que se acumule calor
Una estructura compacta puede dificultar la ventilación.
Solución:
dejar huecos;
no encerrar la fuente;
añadir ventiladores;
medir temperatura;
no cubrir rejillas de router/switch.
4. Que el cableado quede bonito pero poco mantenible
A veces se ordenan tanto los cables que luego no se puede desmontar nada.
Solución:
dejar holgura;
usar bridas reutilizables en la fase inicial;
etiquetar;
no ocultar completamente los cables críticos;
poder sacar la Raspberry sin desmontar toda la maleta.
5. Que LEGO no sea suficiente para elementos pesados
Algunos componentes pueden necesitar sujeción más fuerte.
Solución:
usar LEGO como guía o posicionamiento;
reforzar con tornillos, velcro industrial o bridas;
colocar elementos pesados en el fondo, no en la tapa.
Posibles ampliaciones futuras
El uso de LEGO Technic deja abierta la puerta a muchas ampliaciones:
añadir otra Raspberry;
incluir un pequeño panel de sensores;
montar una pantalla diferente;
añadir un ventilador adicional;
colocar puertos RJ45 externos;
integrar un medidor de consumo;
añadir luces de estado;
preparar soportes para pendrives o tarjetas microSD;
crear una zona para Arduino;
montar un pequeño panel de control.
El diseño no queda cerrado desde el principio, que es precisamente lo que busco.
Primer diseño conceptual
Una primera versión del interior podría ser:
TAPA ┌──────────────────────────────────────────────┐ │ Pantalla │ │ │ │ Router/AP Switch │ │ │ │ Guía de cables Ethernet │ └──────────────────────────────────────────────┘
FONDO ┌──────────────────────────────────────────────┐ │ Fuente 12 V Caja fusibles │ │ │ │ Conversores Raspberry Pi │ │ │ │ SSD / Hub USB Canalización de cables │ └──────────────────────────────────────────────┘
Otra opción sería dejar la tapa solo para pantalla y cableado ligero:
TAPA ┌──────────────────────────────────────────────┐ │ Pantalla │ │ Panel visual / esquema │ │ Guías de cables │ └──────────────────────────────────────────────┘
Todavía no tengo decidido el diseño final. La elección dependerá del tamaño real de la maleta, la altura disponible y cómo cierren los elementos.
Decisiones importantes de esta fase
Antes de avanzar, tengo que decidir varias cosas:
¿Qué elementos irán en la tapa?
¿Qué elementos irán en el fondo?
¿Dónde irá la zona de 230 V?
¿Dónde irá la fuente de alimentación?
¿Cómo entrará y saldrá el aire?
¿Dónde irán los puertos de red accesibles?
¿La pantalla será fija o desmontable?
¿Usaré SSD o HDD?
¿Cuántos niveles tendrá la estructura?
¿Qué partes serán definitivas y cuáles provisionales?
Estas decisiones no tienen que resolverse todas de golpe. El proyecto irá avanzando por pruebas.
Conclusión
En esta segunda fase del proyecto he decidido centrarme en el diseño físico del laboratorio móvil.
La solución elegida será utilizar LEGO Technic y planchas base para crear una estructura modular dentro de la maleta. Esto me permitirá ir montando soportes, niveles y guías de cableado sin necesidad de fabricar piezas a medida desde el principio.
No es una solución industrial ni pretende serlo. Es una solución práctica, flexible y educativa. Me permitirá avanzar sin bloquearme por no tener conocimientos de carpintería o mecanizado, y además facilitará que el proceso sea visual y fácil de explicar.
Eso sí, habrá límites claros: la parte de 230 V tendrá que estar correctamente protegida, los elementos pesados necesitarán sujeción adicional y el cableado de alimentación deberá hacerse con materiales adecuados.
El objetivo de esta fase no es dejar la maleta terminada, sino construir la primera versión del chasis interno: una base modular sobre la que seguir creciendo.
A partir de aquí, el siguiente paso será comenzar las pruebas reales de distribución: colocar las planchas, presentar los componentes, comprobar alturas, pensar rutas de cableado y empezar a construir los primeros soportes.
Montaje de una maleta-laboratorio con router, mini PC, pantalla y alimentación integrada
En este artículo voy a documentar el proceso de montaje de una maleta técnica pensada para funcionar como laboratorio portátil de redes, servidores y pruebas con pequeños dispositivos.
La idea era crear una especie de maleta-laboratorio, donde poder integrar varios elementos de red y computación en un único espacio transportable:
Un router Xiaomi AX3600 desmontado.
Un mini PC o placa de servidor.
Una pantalla integrada en la tapa.
Una fuente de alimentación interna.
Un sistema de distribución eléctrica.
Ventilación forzada mediante ventiladores.
Espacio modular para futuras ampliaciones.
Superficie interior preparada con placas tipo LEGO para fijar componentes.
El objetivo no era simplemente meter dispositivos dentro de una caja, sino crear una estructura ordenada, ampliable y relativamente fácil de modificar.
1. La idea inicial
El proyecto parte de una maleta rígida de aluminio con el tamaño suficiente para alojar varios dispositivos. Este tipo de maleta resulta interesante porque ofrece rigidez estructural, tapa abatible, espacio interno aprovechable y facilidad para transportar todo el conjunto.
La intención era convertirla en una pequeña estación de trabajo portátil, útil para prácticas de redes, ciberseguridad, servidores, monitorización o simulación de infraestructura.
No se trata de un producto comercial terminado, sino de un proyecto artesanal, experimental y flexible, pensado para poder ir evolucionando con el tiempo.
2. Desmontaje del router Xiaomi AX3600
Uno de los primeros pasos fue desmontar el router Xiaomi AX3600 para poder integrarlo dentro de la maleta.
El router, en su formato original, ocupa bastante espacio debido a la carcasa y a la disposición de las antenas. Para aprovechar mejor el interior de la maleta, se retiró la carcasa y se dejó accesible la placa principal.
Durante el desmontaje se separaron los elementos principales del router:
La placa principal.
El disipador.
Los conectores internos de antena.
Las antenas externas.
La chapa metálica de soporte.
Los cables coaxiales internos.
Este paso permite reducir el volumen del dispositivo y facilita su integración dentro de una estructura personalizada.
Importante: Este tipo de modificación anula cualquier garantía del dispositivo y debe hacerse con mucho cuidado. Hay que evitar tirar de los cables de antena, doblar conectores o provocar cortocircuitos sobre la placa.
3. Separación de carcasa, antenas y placa principal
Una vez abierto el router, se separaron la carcasa superior, la carcasa inferior, las antenas, la placa principal y el soporte metálico.
La placa del router se mantuvo junto a su disipador y parte de la estructura metálica, ya que esto ayuda a conservar rigidez y facilita su posterior fijación dentro de la maleta.
Las antenas originales también se conservaron. En lugar de mantenerlas unidas a la carcasa del router, se recolocaron en otra zona de la maleta para aprovechar mejor el espacio disponible.
Este paso es delicado porque los cables de antena son finos y frágiles. No conviene doblarlos en exceso ni forzar los conectores pequeños que van unidos a la placa.
4. Preparación de la base interior de la maleta
Para poder fijar componentes dentro de la maleta, se preparó una base modular usando placas tipo LEGO.
Este sistema permite colocar, mover y reorganizar piezas sin tener que taladrar constantemente la maleta. Es una solución muy práctica para un proyecto que puede cambiar con el tiempo.
La base interior se dividió en varias zonas funcionales:
Zona de alimentación.
Zona de router o electrónica de red.
Zona para mini PC o placa principal.
Zona de ventilación.
Zona para distribución de cables.
Zona libre para ampliaciones.
El uso de una superficie modular permite probar distintas distribuciones antes de fijar los elementos de forma definitiva. También facilita futuras modificaciones, como añadir una Raspberry Pi, un switch, sensores, más conectores o nuevos módulos.
5. Corte de huecos para ventilación
Uno de los puntos más importantes del proyecto fue la refrigeración. Al meter electrónica dentro de una maleta cerrada, el calor puede acumularse rápidamente.
Por este motivo se prepararon varios huecos para ventiladores. La intención era crear circulación de aire dentro del conjunto y evitar que la temperatura aumentase demasiado durante el uso.
El sistema de ventilación se planteó con tres ideas principales:
Permitir la entrada de aire fresco.
Facilitar la salida de aire caliente.
Mover el aire interno para evitar zonas de calor acumulado.
En este tipo de montaje conviene decidir bien el sentido del flujo de aire. No basta con poner ventiladores sin más. Si todos meten aire, puede faltar salida. Si todos sacan aire, puede faltar entrada. Lo recomendable es combinar entrada y salida para crear un flujo continuo.
6. Instalación de la pantalla en la tapa
Otro elemento importante del proyecto fue la instalación de una pantalla en la tapa de la maleta.
La pantalla permite usar la maleta sin depender siempre de un monitor externo. Puede servir para mostrar la consola del sistema, una interfaz gráfica, información de estado, dashboards de monitorización o herramientas de administración.
Integrar la pantalla en la tapa convierte esa parte de la maleta en una especie de panel de control. Además, deja libre la base para la fuente de alimentación, el mini PC, el cableado y otros dispositivos.
La pantalla se fijó en una zona visible y accesible, dejando espacio alrededor para conectores, botones, indicadores u otros elementos que puedan añadirse más adelante.
7. Colocación de conectores y acceso exterior
Además de la pantalla, se prepararon zonas de acceso para conectores y controles.
La idea de sacar conectores al panel es muy útil porque evita tener que manipular directamente las placas internas cada vez que se quiere conectar algo.
En un montaje de este tipo conviene dejar accesibles elementos como:
Entrada de alimentación.
Interruptor general.
Puertos Ethernet.
Puertos USB.
HDMI, si se necesita.
Conexión de pantalla.
Botones de encendido.
Indicadores luminosos.
Salidas de 5 V o 12 V, si se quieren usar.
Diseñar bien los accesos desde el principio evita tener que abrir la maleta constantemente para conectar o desconectar dispositivos.
8. Instalación del conector IEC con interruptor
Para alimentar la maleta se instaló un conector IEC con interruptor. Este tipo de conector es habitual en ordenadores, fuentes de alimentación y equipos electrónicos.
El conector permite tener una entrada de corriente más limpia y segura que un cable suelto. Además, al incluir interruptor, se puede encender y apagar toda la maleta desde un único punto.
Este elemento se pensó como entrada principal de alimentación del proyecto.
Aviso de seguridad: La parte de 230 V debe estar muy bien aislada, protegida y fijada. No debe quedar ningún terminal expuesto. Es recomendable usar funda termorretráctil, conectores faston aislados, clemas adecuadas, fusible y toma de tierra si la fuente y la estructura lo requieren.
En esta fase es importante separar claramente la zona de alta tensión de la zona de baja tensión. La entrada de 230 V debe quedar protegida y no mezclarse con cables de datos o electrónica de bajo voltaje.
9. Fuente de alimentación y distribución eléctrica
La fuente de alimentación se instaló en la base de la maleta, separada del resto de componentes principales.
Su función es convertir la entrada de corriente alterna en salidas de corriente continua, que después se pueden distribuir a los distintos elementos del montaje.
Desde la fuente se llevó la alimentación a una bornera o bloque de distribución. Esto permite repartir energía de forma más ordenada a distintos dispositivos:
Router.
Ventiladores.
Convertidores DC-DC.
Mini PC o placa.
Pantalla.
Otros módulos internos.
El uso de una bornera de distribución evita empalmes improvisados y facilita el mantenimiento. Cada línea puede salir desde un punto concreto, con positivo y negativo claramente identificados.
Lo ideal es que cada salida importante tenga su propia protección, especialmente si se van a alimentar varios dispositivos desde la misma fuente.
10. Organización del cableado
Uno de los retos principales fue la organización del cableado.
A medida que se añaden elementos, aparecen cables de alimentación, cables USB, HDMI, Ethernet, antenas, ventiladores y conexiones internas. Si no se planifica bien, el interior puede volverse difícil de mantener.
Para mejorar la organización del cableado conviene seguir varias reglas:
Separar alimentación y datos.
Usar bridas pequeñas.
Etiquetar cables importantes.
Mantener colores coherentes.
Usar rojo para positivo.
Usar negro para negativo.
Evitar que los cables pasen por encima de disipadores.
Evitar que los cables puedan tocar ventiladores.
Dejar holgura suficiente para abrir y cerrar la tapa.
No tensar cables de antena ni conectores delicados.
Un cableado bien organizado no solo mejora la estética, también facilita detectar fallos, sustituir piezas y ampliar el proyecto.
11. Recolocación de las antenas del router
Una de las partes más importantes del montaje fue la recolocación de las antenas del router Xiaomi AX3600.
En lugar de mantener el router completo con su carcasa original, las antenas se distribuyeron por la tapa de la maleta. De esta manera se aprovecha mejor el espacio y se libera la base para otros componentes.
Las antenas se colocaron en una posición que permite conservar su función original y mantener una buena separación entre ellas. Esto es importante en un router con varias antenas, ya que su distribución influye en la cobertura y en el rendimiento inalámbrico.
Durante esta parte del montaje hay que cuidar especialmente los cables coaxiales. Son muy finos y no deben doblarse en ángulos bruscos. También hay que evitar que queden tirantes al abrir o cerrar la maleta.
12. Montaje de la placa del router en la maleta
La placa del router se integró dentro de la maleta junto con su disipador y parte de su soporte metálico.
La idea fue aprovechar el router como elemento principal de red, pero sin conservar la carcasa original. De esta forma se gana espacio y se puede colocar el hardware en una posición más adecuada para el conjunto.
La placa debe quedar bien sujeta y aislada. No debe tocar directamente superficies metálicas sin protección, porque podría producirse un cortocircuito.
Para fijar este tipo de placas conviene usar:
Separadores.
Tornillos adecuados.
Soportes plásticos.
Arandelas de nylon.
Bases no conductoras.
Piezas modulares.
Cinta aislante en zonas críticas.
También es importante que el disipador tenga espacio suficiente alrededor para evacuar calor.
13. Instalación del mini PC o placa principal
En la base de la maleta se instaló un mini PC o placa compacta que puede funcionar como servidor principal del proyecto.
Este equipo puede utilizarse para diferentes funciones, dependiendo del sistema operativo y de los servicios instalados:
Servidor Linux.
Proxmox.
Docker.
Portainer.
Servidor web.
Base de datos.
Monitorización.
Laboratorio de redes.
Nodo de ciberseguridad.
Panel de administración.
Este tipo de placa resulta muy adecuada para una maleta-laboratorio porque ocupa poco espacio, consume relativamente poco y ofrece muchas posibilidades.
En un contexto educativo, puede funcionar como servidor central para prácticas de clase, despliegue de servicios, pruebas de red o administración remota.
14. Posibles usos de la maleta-laboratorio
Una vez montada, la maleta puede tener muchos usos en clase o en un entorno de pruebas.
Laboratorio de redes
La maleta puede funcionar como pequeño centro de red portátil. Permite trabajar conceptos como:
Configuración IP.
DHCP.
DNS.
NAT.
Redes WiFi.
Segmentación de red.
Pruebas de conectividad.
Administración de router.
Acceso remoto.
Si en el futuro se añade un switch gestionable, también podría usarse para trabajar VLAN y escenarios de red más avanzados.
Laboratorio de ciberseguridad
También puede utilizarse como base para prácticas de ciberseguridad:
Monitorización de tráfico.
IDS con Suricata.
Wazuh.
Captura de paquetes.
Análisis con Wireshark.
Laboratorios con máquinas vulnerables.
Pruebas de firewall.
Segmentación de entornos.
La ventaja de tenerlo todo dentro de una maleta es que el entorno puede transportarse y desplegarse rápidamente.
Servidor portátil
El mini PC permite convertir la maleta en un pequeño servidor portátil.
Algunos servicios interesantes que podrían instalarse son:
Docker.
Portainer.
Nginx.
Apache.
MariaDB.
Grafana.
Prometheus.
Open WebUI.
Servicios internos para clase.
Esto permite llevar un entorno completo preparado sin depender de infraestructura externa.
Proyecto educativo
La propia construcción de la maleta ya es un proyecto educativo interesante.
Permite trabajar contenidos de:
Electricidad básica.
Electrónica.
Hardware.
Redes.
Refrigeración.
Seguridad.
Organización interna.
Documentación técnica.
Resolución de problemas.
Es un proyecto muy completo porque obliga a pensar tanto en la parte técnica como en la parte física del montaje.
15. Problemas y aprendizajes durante el montaje
Este tipo de proyecto no queda perfecto a la primera. Es normal tener que probar, desmontar, recolocar y corregir.
Algunos aprendizajes importantes del proceso fueron:
Antes de fijar nada definitivamente, conviene presentar todos los componentes.
El espacio interior se acaba antes de lo que parece.
El cableado ocupa mucho más de lo previsto.
La ventilación debe pensarse desde el principio.
Los conectores deben quedar accesibles.
Las piezas modulares ayudan mucho.
La alimentación debe planificarse con cuidado.
Conviene dejar margen para futuras ampliaciones.
La tapa también puede aprovecharse como zona de montaje.
La estética importa, pero la seguridad importa más.
Uno de los mayores aciertos fue usar placas tipo LEGO como superficie modular. Esta solución permite modificar el diseño sin rehacer completamente la estructura.
🎧 Resumen en audio del tema Escucha este breve audio para repasar las ideas principales de los fundamentos de redes informáticas antes de continuar o al finalizar la lectura.
Cuando hablamos de redes informáticas, muchas veces pensamos solo en cables, routers, switches o conexión a Internet. Sin embargo, una red no funciona de verdad solo por estar físicamente conectada. Para que varios equipos puedan compartir recursos, trabajar de forma organizada y mantener la seguridad, hace falta una capa de software que controle todo ese entorno.
Ahí es donde entran en juego los Sistemas Operativos de Red (SOR) y la familia de protocolos TCP/IP.
Un sistema operativo de red permite administrar usuarios, equipos, permisos, recursos compartidos y servicios. Por su parte, TCP/IP proporciona el lenguaje común que utilizan los dispositivos para comunicarse, tanto dentro de una red local como a través de Internet.
En este tema vamos a estudiar los fundamentos de ambos conceptos, viendo cómo se gestionan usuarios y accesos en entornos profesionales, cómo funcionan las redes en sistemas Microsoft y por qué TCP/IP es la base de prácticamente todas las comunicaciones actuales.
1. El Sistema Operativo de Red (SOR)
Un Sistema Operativo de Red es un sistema diseñado para permitir la comunicación, administración y uso compartido de recursos entre varios equipos conectados en red.
Su misión principal es coordinar el acceso a los recursos y garantizar que los usuarios puedan trabajar de manera simultánea, ordenada y segura.
¿Por qué es necesario un SOR?
Imagina una red con 20 ordenadores en un aula, oficina o empresa. Si cada equipo gestionara sus propios usuarios, sus propias contraseñas, sus propias carpetas compartidas y sus propios permisos de forma independiente, el resultado sería un auténtico caos:
los usuarios tendrían múltiples cuentas distintas,
sería difícil controlar quién accede a qué,
la administración sería lenta y repetitiva,
la seguridad sería mucho más débil.
Un sistema operativo de red evita ese desorden, centralizando o coordinando la gestión del entorno.
2. Tipos de sistemas operativos
Podemos distinguir dos grandes grupos:
2.1. Sistemas operativos de escritorio
Son los diseñados para el uso cotidiano de un único usuario sobre un equipo concreto.
Ejemplos:
Windows 10
Windows 11
Ubuntu Desktop
Linux Mint
Fedora Workstation
Están orientados a tareas como navegación web, ofimática, reproducción multimedia o programación local.
2.2. Sistemas operativos de servidor
Están preparados para funcionar de manera estable durante largos periodos de tiempo, gestionando servicios, usuarios, permisos y recursos compartidos.
Ejemplos:
Windows Server
Ubuntu Server
Debian Server
Red Hat Enterprise Linux
AlmaLinux
Estos sistemas suelen utilizarse para ofrecer servicios como:
autenticación de usuarios,
almacenamiento de archivos,
servidores web,
bases de datos,
impresión en red,
copias de seguridad,
control de dominios.
3. Arquitectura cliente-servidor
En una red profesional, lo habitual es trabajar con una arquitectura cliente-servidor.
¿Qué significa esto?
Cliente: equipo o programa que solicita un recurso o servicio.
Servidor: equipo o programa que ofrece ese recurso o servicio.
Por ejemplo:
un navegador web es cliente cuando solicita una página,
un servidor web entrega esa página,
un ordenador de aula puede actuar como cliente,
un servidor central puede almacenar usuarios y carpetas compartidas.
Ventajas de este modelo
centraliza la administración,
facilita el control de usuarios y permisos,
mejora la seguridad,
permite escalar mejor la red,
simplifica el mantenimiento.
Ejemplo real
En un instituto, los alumnos pueden iniciar sesión en distintos ordenadores usando la misma cuenta de red. Eso es posible porque existe un servidor que centraliza la autenticación, los permisos y, en muchos casos, sus carpetas personales.
4. Gestión de usuarios, derechos y accesos
Una red profesional no puede funcionar correctamente si no está bien definida la gestión de identidades y permisos.
No basta con que un usuario “entre” al sistema. También hay que controlar qué puede hacer, dónde puede hacerlo y hasta qué punto.
5. Usuario vs. persona
Es importante no confundir ambos conceptos.
Persona
Es el individuo real: un alumno, un profesor, un técnico, un empleado.
Usuario
Es la identidad digital con la que esa persona accede al sistema.
Una misma persona puede tener:
una cuenta corporativa,
una cuenta de administrador,
una cuenta de pruebas,
o incluso no tener ninguna cuenta en un sistema concreto.
Idea clave
Las cuentas de usuario no deben compartirse. Cada acción realizada en un sistema debe poder asociarse a una identidad concreta. Esto permite:
mantener la trazabilidad,
exigir responsabilidad,
investigar incidencias,
reforzar la seguridad.
6. Usuarios locales y usuarios de red
Usuarios locales
Son cuentas que existen únicamente en un equipo concreto.
Ejemplo: un usuario creado en un PC con Windows o en una máquina Linux local.
Características:
solo sirven en ese equipo,
no se comparten automáticamente con otros dispositivos,
son útiles en entornos pequeños o aislados.
Usuarios de red
Son cuentas almacenadas y gestionadas desde un servidor central.
Características:
permiten iniciar sesión desde distintos equipos de la red,
centralizan la autenticación,
facilitan la administración,
son la base de los entornos profesionales.
Comparativa rápida
Tipo de usuario
Dónde se almacena
Dónde puede usarse
Administración
Local
En un único equipo
Solo en ese equipo
Individual
De red
En un servidor central
En varios equipos de la red
Centralizada
7. Grupos de usuarios
En redes medianas o grandes, asignar permisos usuario por usuario es una mala idea. Es lento, propenso a errores y difícil de mantener.
Por eso se usan los grupos.
¿Qué es un grupo?
Es una agrupación lógica de usuarios con características o necesidades similares.
Ejemplos:
Alumnos
Profesores
Administración
Soporte
Dirección
Ventajas de usar grupos
simplifican la gestión,
permiten aplicar permisos de forma masiva,
facilitan altas y bajas,
reducen errores administrativos.
Ejemplo
En lugar de dar permiso manual a 30 alumnos sobre una carpeta, se crea el grupo Alumnos y se asigna el permiso una sola vez a ese grupo.
Cuando llega un nuevo alumno, basta con añadirlo al grupo.
8. Derechos y permisos
Aunque a veces se usan como sinónimos, no son exactamente lo mismo.
Derechos
Son capacidades del usuario sobre el sistema.
Ejemplos:
iniciar sesión,
apagar el equipo,
administrar el sistema,
instalar software,
acceder por escritorio remoto.
Permisos
Son autorizaciones sobre un recurso concreto.
Ejemplos:
leer un archivo,
modificar una carpeta,
ejecutar un programa,
borrar un documento,
controlar totalmente un recurso.
Permisos más habituales
Permiso
Qué permite
Lectura
Ver el contenido
Escritura
Crear o modificar
Ejecución
Ejecutar archivos o programas
Modificación
Cambiar y borrar contenido
Control total
Gestión completa del recurso
Herencia de permisos
Muchos sistemas permiten que una carpeta herede permisos de su carpeta superior. Esto facilita la administración, pero también puede provocar errores si no se revisa bien.
Ejemplo:
Carpeta principal: Documentos_Profesorado
Subcarpeta: Exámenes
Si la subcarpeta hereda permisos, podría estar accesible para más usuarios de los deseados si la carpeta principal estaba mal configurada.
9. Autenticación y autorización
Son dos conceptos básicos y diferentes.
Autenticación
Responde a la pregunta: ¿Quién eres?
Se verifica la identidad del usuario mediante:
nombre de usuario y contraseña,
PIN,
huella dactilar,
tarjeta inteligente,
doble factor de autenticación.
Autorización
Responde a la pregunta: ¿Qué puedes hacer?
Una vez que el usuario ya ha demostrado quién es, el sistema decide:
a qué carpetas puede entrar,
qué programas puede usar,
si puede imprimir,
si puede instalar software,
si puede administrar el equipo.
Ejemplo sencillo
Un alumno inicia sesión correctamente en la red del centro:
La autenticación ha sido correcta.
Pero si intenta entrar en la carpeta de profesores y el sistema se lo impide, ahí entra en juego la autorización.
10. Principio de mínimo privilegio
Uno de los principios más importantes en administración y seguridad es el principio de mínimo privilegio.
¿Qué significa?
Cada usuario debe tener únicamente los permisos imprescindibles para realizar su trabajo. Ni más, ni menos.
¿Por qué es tan importante?
Porque reduce:
errores accidentales,
borrados no intencionados,
accesos indebidos,
impacto de un malware,
abuso de privilegios.
Ejemplo
Un alumno no necesita privilegios de administrador en los equipos del aula. Un profesor tampoco debería tener acceso total al servidor si no es necesario. Un técnico puede tener más permisos, pero solo en los sistemas que debe gestionar.
Dar permisos de más parece cómodo al principio, pero suele acabar generando problemas.
11. Redes en sistemas Microsoft
Los entornos Microsoft han sido históricamente muy usados en empresas, centros educativos y administraciones públicas.
Windows utiliza TCP/IP de forma nativa para comunicarse en red y ofrece mecanismos específicos para compartir recursos, autenticar usuarios y administrar equipos.
12. Protocolos clave en entornos Microsoft
12.1. SMB (Server Message Block)
Es el protocolo utilizado para compartir:
archivos,
carpetas,
impresoras,
recursos de red.
Cuando en Windows accedes a una carpeta compartida como:
\\SERVIDOR\DOCUMENTOS
normalmente estás usando SMB.
12.2. Kerberos
Es un protocolo de autenticación muy utilizado en dominios Windows.
Su objetivo es verificar la identidad de los usuarios de forma segura, evitando enviar la contraseña constantemente por la red.
Kerberos funciona mediante tickets y es una pieza esencial en Active Directory.
12.3. DNS
Es el sistema que traduce nombres a direcciones IP.
Ejemplo:
Nombre: servidor-aula.local
IP: 192.168.1.20
Hoy es fundamental en redes Microsoft, ya que muchos servicios de dominio dependen de una resolución de nombres correcta.
12.4. NetBIOS
Fue muy importante en redes Windows antiguas para identificar equipos y compartir recursos por nombre.
Actualmente su uso es mucho menor, y en redes modernas ha sido desplazado en gran medida por DNS y otros mecanismos más actuales.
13. Grupo de trabajo y dominio
En Windows existen dos formas clásicas de organizar una red: grupo de trabajo y dominio.
13.1. Grupo de trabajo
Es un modelo simple en el que no existe un servidor central de autenticación.
Cada equipo:
mantiene sus propias cuentas locales,
comparte sus propios recursos,
administra sus propios permisos.
Ventajas
sencillo de montar,
útil en redes pequeñas,
no requiere servidor central.
Inconvenientes
poca seguridad,
mala escalabilidad,
administración repetitiva,
poca trazabilidad.
13.2. Dominio
Es el modelo profesional. En él existe un servidor central, normalmente con Windows Server y Active Directory, que gestiona:
usuarios,
grupos,
políticas,
equipos,
permisos,
recursos compartidos.
Ventajas
administración centralizada,
mejor seguridad,
más control,
mayor escalabilidad,
aplicación uniforme de políticas.
Inconvenientes
mayor complejidad,
requiere servidor y configuración específica.
Comparativa
Característica
Grupo de trabajo
Dominio
Gestión de usuarios
Local en cada equipo
Centralizada
Seguridad
Limitada
Alta
Escalabilidad
Baja
Alta
Administración
Desordenada en redes grandes
Mucho más eficiente
Uso recomendado
Redes pequeñas
Empresas, centros educativos, organizaciones
14. La familia de protocolos TCP/IP
Si el sistema operativo de red organiza el entorno, TCP/IP hace posible la comunicación.
La familia TCP/IP es el conjunto de protocolos que permite que los datos viajen entre dispositivos, tanto en redes locales como en Internet.
Es el estándar real y práctico utilizado hoy en día.
TCP/IP frente al modelo OSI
Aunque muchas veces se estudia el modelo OSI de 7 capas por motivos didácticos, en la práctica TCP/IP suele representarse en 4 capas:
Aplicación
Transporte
Internet
Acceso a red
15. Capa de Aplicación
Es la capa más cercana al usuario y a los programas que utiliza.
Aquí trabajan los protocolos que permiten servicios concretos.
Protocolos destacados
HTTP y HTTPS
Permiten acceder a páginas web.
HTTP transmite información sin cifrar.
HTTPS añade cifrado mediante TLS/SSL, protegiendo contraseñas, formularios y datos sensibles.
DNS
Convierte nombres de dominio en direcciones IP.
Ejemplo:
www.google.com → una IP concreta
Sin DNS, tendríamos que recordar direcciones IP numéricas para visitar cualquier servicio.
DHCP
Asigna automáticamente parámetros de red a los equipos.
Por ejemplo:
dirección IP,
máscara de subred,
puerta de enlace,
servidores DNS.
Gracias a DHCP, un usuario puede conectar su portátil a una red y obtener configuración automáticamente sin tener que escribirla a mano.
16. Capa de Transporte
Se encarga de transportar los datos entre aplicaciones de origen y destino.
También utiliza los puertos, que permiten distinguir qué aplicación debe recibir la información.
Ejemplos:
puerto 80 → HTTP
puerto 443 → HTTPS
puerto 53 → DNS
puerto 25 → SMTP
Protocolos principales
TCP (Transmission Control Protocol)
Es un protocolo orientado a conexión y fiable.
Se asegura de que:
los datos lleguen,
lleguen completos,
lleguen en orden,
se retransmitan si algo falla.
Se utiliza en servicios donde la integridad importa mucho, como:
navegación web,
transferencia de archivos,
correo electrónico,
acceso remoto seguro.
UDP (User Datagram Protocol)
Es mucho más ligero y rápido que TCP, pero no garantiza:
entrega,
orden,
retransmisión.
Se usa cuando la velocidad importa más que la perfección.
Ejemplos:
streaming,
videollamadas,
juegos online,
ciertos servicios de DNS.
Comparativa TCP vs UDP
Característica
TCP
UDP
Fiabilidad
Alta
Baja
Control de entrega
Sí
No
Orden de llegada
Sí
No
Velocidad
Menor
Mayor
Uso típico
Web, archivos, correo
Streaming, voz, juegos
17. Capa de Internet
Es la encargada del direccionamiento lógico y del encaminamiento de los paquetes hacia su destino.
Aquí se decide cómo llegar desde un origen hasta una máquina situada en otra red.
Protocolos principales
IP (Internet Protocol)
Es el protocolo fundamental del direccionamiento.
Cada equipo conectado a una red necesita una dirección IP para poder identificarse y comunicarse.
Ejemplo de IP privada:
192.168.1.34
IP no garantiza por sí sola que los datos lleguen correctamente. Esa fiabilidad, cuando se necesita, la aporta TCP.
ICMP (Internet Control Message Protocol)
Se utiliza para diagnóstico y control.
Un ejemplo muy conocido es el comando:
ping
Cuando hacemos ping a una dirección o a un nombre de dominio, normalmente se están enviando mensajes ICMP para comprobar si existe conectividad.
Ejemplo de uso
Si un equipo no puede acceder a Internet, una de las primeras pruebas suele ser:
hacer ping a su puerta de enlace,
hacer ping a una IP externa,
hacer ping a un nombre de dominio.
Con eso se puede empezar a distinguir si el problema es de conectividad o de resolución DNS.
18. Capa de Acceso a Red
Es la capa donde el software se encuentra con el hardware.
Aquí se trabaja con:
tarjetas de red,
direcciones MAC,
tramas,
medios físicos,
señales eléctricas, ópticas o inalámbricas.
Tecnologías habituales
Ethernet
Wi-Fi
Dirección MAC
Cada interfaz de red tiene asociada una dirección física o MAC.
Esta dirección se utiliza en la comunicación dentro de la red local.
Mientras que la IP identifica lógicamente al equipo en una red, la MAC identifica físicamente la interfaz en el nivel de acceso a red.
19. El viaje de los datos: ejemplo completo
Vamos a ver qué ocurre cuando un usuario abre una página web.
Situación
Un alumno escribe en el navegador:
https://www.ejemplo.com
Paso 1: Capa de Aplicación
El navegador necesita acceder al sitio web.
Si no conoce la IP del servidor, utiliza DNS para resolver el nombre.
Después prepara la comunicación usando HTTPS.
Paso 2: Capa de Transporte
Se utiliza normalmente TCP porque interesa que los datos lleguen correctamente.
El navegador se comunica con el puerto 443, que corresponde a HTTPS.
Paso 3: Capa de Internet
Los datos se encapsulan en paquetes IP.
La dirección IP de origen será la del ordenador del alumno y la IP de destino será la del servidor web.
Paso 4: Capa de Acceso a Red
Los paquetes se convierten en tramas y se envían físicamente por la red mediante Ethernet o Wi-Fi.
Resultado
El servidor recibe la petición, responde, y el proceso inverso permite que la página llegue al navegador del usuario.
20. Relación entre administración de red y TCP/IP
Estos dos bloques no deben estudiarse por separado como si no tuvieran relación.
En realidad, están totalmente conectados.
El sistema operativo de red organiza usuarios, equipos, permisos y recursos.
TCP/IP permite que todos esos elementos puedan comunicarse.
Por ejemplo:
un usuario inicia sesión contra un servidor,
una carpeta compartida se accede por red,
una impresora se usa remotamente,
un controlador de dominio resuelve nombres y autentica identidades,
un servidor DHCP asigna IP a los clientes.
Todo eso se apoya sobre TCP/IP.
21. Ejemplos prácticos del día a día
Ejemplo 1: Inicio de sesión en un aula
Un alumno enciende un ordenador del aula e introduce su usuario y contraseña.
El sistema autentica su identidad.
Se aplican sus permisos.
Puede acceder a sus recursos de red.
Ejemplo 2: Carpeta compartida de profesores
Solo el grupo de profesores debe poder acceder a una carpeta con exámenes.
Se crea un grupo llamado Profesores.
Se asignan permisos a ese grupo.
Los alumnos no tienen acceso.
Ejemplo 3: Asignación automática de red
Un portátil se conecta al Wi-Fi del centro.
DHCP le entrega una IP.
DNS le permite resolver nombres.
TCP/IP hace posible toda la comunicación.
Ejemplo 4: Diagnóstico básico
Un usuario dice que “Internet no funciona”.
El técnico puede comprobar:
si tiene IP,
si responde la puerta de enlace,
si funciona DNS,
si hay conectividad con el exterior.
22. Errores habituales que conviene evitar
En administración de red hay varios errores muy frecuentes:
Compartir cuentas de usuario
Rompe la trazabilidad y reduce la seguridad.
Asignar permisos uno a uno
Hace la gestión lenta y propensa a errores. Es mejor usar grupos.
Dar privilegios excesivos
Aumenta el riesgo de accidentes y abusos.
No revisar herencias de permisos
Puede dejar recursos accesibles a usuarios no autorizados.
Pensar que “tener red” es solo tener Internet
Una red bien administrada implica mucho más: usuarios, recursos, permisos, autenticación y organización.
No diferenciar autenticación de autorización
Un usuario puede estar autenticado correctamente y aun así no tener permiso para acceder a un recurso.
Un sistema operativo de red es la base organizativa que permite que una red funcione de manera controlada, segura y eficiente. Gracias a él es posible gestionar usuarios, grupos, permisos, servicios y equipos desde una perspectiva global.
En entornos profesionales, el modelo cliente-servidor y la administración centralizada son esenciales para evitar el desorden y reforzar la seguridad. En ese contexto, conceptos como autenticación, autorización, grupos de usuarios y mínimo privilegio son fundamentales.
Por otro lado, la familia de protocolos TCP/IP constituye la base de la comunicación moderna. Sus capas permiten que los datos viajen desde una aplicación concreta hasta el medio físico, pasando por el transporte, el direccionamiento y el acceso a red.
Entender estos fundamentos no es opcional para cualquier administrador de sistemas o técnico de redes: es la base sobre la que se construyen servicios más avanzados como dominios, servidores web, compartición de archivos, monitorización, seguridad y administración centralizada.
Ideas clave
Un sistema operativo de red no solo conecta equipos: organiza, controla y protege los recursos compartidos.
Una persona y un usuario no son lo mismo: el usuario es su identidad digital.
En redes profesionales, los permisos deben gestionarse mediante grupos, no usuario por usuario.
Autenticación es demostrar quién eres; autorización es determinar qué puedes hacer.
El principio de mínimo privilegio reduce riesgos y mejora la seguridad.
En entornos Microsoft, SMB, Kerberos y DNS son tecnologías fundamentales.
TCP/IP es el conjunto de protocolos que hace posible la comunicación en redes e Internet.
TCP prioriza la fiabilidad; UDP prioriza la rapidez.
IP direcciona los paquetes y ICMP ayuda a diagnosticar problemas de conectividad.
🎧 Resumen en audio del tema Escucha este breve audio para repasar las ideas principales de los fundamentos de redes informáticas antes de continuar o al finalizar la lectura.
Vivimos en una sociedad permanentemente conectada. Cada vez que enviamos un mensaje desde el teléfono móvil, vemos un vídeo en streaming o accedemos a una página web, estamos utilizando una red informática.
Las redes surgieron para resolver una necesidad muy concreta: permitir que los ordenadores dejaran de trabajar de forma aislada y pudieran compartir información, recursos y servicios de manera rápida, eficiente y económica.
Pero, ¿qué es exactamente una red? ¿Cómo consiguen comunicarse entre sí nuestros dispositivos en cuestión de milisegundos, incluso estando a miles de kilómetros de distancia?
En este tema vamos a estudiar los conceptos básicos de redes informáticas: los tipos de redes según su alcance, los dispositivos que las forman, las topologías más habituales, los protocolos que hacen posible la comunicación y el modelo OSI, que nos ayuda a entender cómo viajan los datos de un equipo a otro.
Objetivos del tema
Al finalizar este tema, el alumno será capaz de:
Comprender qué es una red informática y por qué es importante.
Diferenciar los principales tipos de redes según su alcance.
Identificar los elementos básicos que forman una red local.
Entender las topologías más utilizadas en redes.
Reconocer los protocolos fundamentales de comunicación.
Interpretar el modelo OSI y relacionarlo con dispositivos y servicios reales.
1. ¿Qué es una red informática?
Una red informática es un conjunto de dispositivos conectados entre sí que pueden intercambiar información y compartir recursos.
Estos dispositivos pueden ser ordenadores, móviles, impresoras, servidores, tablets, cámaras IP, televisores inteligentes y muchos otros equipos.
Gracias a una red, es posible:
Compartir archivos.
Acceder a impresoras comunes.
Navegar por Internet.
Enviar correos electrónicos.
Utilizar aplicaciones en línea.
Conectarse a servidores y bases de datos.
Ejemplo cotidiano
Cuando conectas tu portátil al Wi-Fi de casa para ver una página web, están interviniendo varios elementos de red: tu tarjeta de red, el router, el proveedor de Internet, servidores intermedios y el servidor final que aloja esa web.
2. Clasificación de las redes según su alcance
Las redes pueden clasificarse según la distancia o el área geográfica que abarcan. De menor a mayor alcance, encontramos los siguientes tipos:
2.1 BAN (Body Area Network)
La BAN es una red de alcance muy reducido, normalmente de centímetros o pocos metros. Se utiliza para conectar dispositivos que se llevan encima del cuerpo o incluso integrados en él.
Ejemplos:
Relojes inteligentes.
Pulseras de actividad.
Sensores médicos.
Dispositivos de monitorización corporal.
2.2 PAN (Personal Area Network)
La PAN conecta dispositivos personales en un radio pequeño, normalmente de unos 10 metros.
Suele utilizar tecnologías de bajo consumo, como Bluetooth.
Ejemplos:
Móvil conectado a auriculares inalámbricos.
Tablet enlazada con un teclado Bluetooth.
Teléfono móvil conectado a un smartwatch.
2.3 LAN (Local Area Network)
La LAN es una red de área local. Conecta dispositivos dentro de un espacio limitado, como:
Un aula.
Una oficina.
Un laboratorio.
Un edificio pequeño.
Se caracteriza por ofrecer:
Alta velocidad.
Baja latencia.
Control privado.
Facilidad para compartir recursos.
Ejemplos:
La red de ordenadores de un aula de informática.
La red de una empresa en una sola planta.
La red interna de un laboratorio.
2.4 HAN (Home Area Network)
La HAN puede considerarse un caso particular de red local, centrada en el entorno doméstico.
Conecta los dispositivos de una vivienda.
Ejemplos:
Ordenadores.
Móviles.
Smart TV.
Consolas.
Impresoras.
Cámaras IP.
Asistentes inteligentes.
2.5 CAN (Campus Area Network)
La CAN conecta varias redes LAN dentro de un recinto más amplio.
Ejemplos:
Una universidad con varios edificios.
Un instituto con distintas sedes.
Un hospital con varias áreas conectadas.
2.6 MAN (Metropolitan Area Network)
La MAN conecta diferentes redes dentro de una misma ciudad o área metropolitana.
Normalmente utiliza infraestructuras de alta capacidad, como fibra óptica.
Ejemplo:
La red que conecta distintas sedes de una administración pública dentro de una ciudad.
2.7 WAN (Wide Area Network)
La WAN es una red de gran extensión geográfica. Permite conectar redes situadas en diferentes ciudades, países o incluso continentes.
Para ello se apoya en infraestructuras de operadores de telecomunicaciones.
Ejemplos:
La red corporativa de una empresa con oficinas en varias ciudades.
Redes bancarias distribuidas por diferentes países.
2.8 GAN (Global Area Network)
La GAN es una red de alcance global que interconecta redes WAN a escala mundial.
Internet es el mayor ejemplo de este tipo de red.
Ejemplos:
Internet.
Redes globales que utilizan satélites y cables submarinos.
3. Elementos clave de una red local
Para construir una red no basta con conectar ordenadores sin más. Es necesario utilizar varios componentes, y cada uno cumple una función específica.
3.1 Equipos finales o hosts
Son los dispositivos que generan o reciben la información.
Ejemplos:
Ordenadores.
Portátiles.
Tablets.
Móviles.
Impresoras.
Cámaras IP.
Smart TV.
Servidores.
Un servidor es un equipo preparado para ofrecer servicios a otros dispositivos de la red, como páginas web, archivos compartidos, correo electrónico o bases de datos.
3.2 Switch (conmutador)
El switch conecta varios dispositivos dentro de una red local cableada.
Su función principal es enviar la información únicamente al equipo destinatario, utilizando para ello la dirección física o MAC.
Idea clave:
El switch organiza el tráfico dentro de la red local.
3.3 Router (enrutador)
El router conecta redes diferentes entre sí.
En una red doméstica o de oficina, el router suele unir:
La red local.
Internet.
Trabaja principalmente con direcciones IP y se encarga de decidir qué ruta debe seguir la información.
Idea clave:
El router es la puerta de salida desde la red local hacia otras redes.
3.4 Módem / ONT
Este dispositivo adapta la señal para que pueda viajar por la infraestructura del proveedor de Internet.
Dependiendo del tipo de conexión, puede tratarse de:
Un módem.
Una ONT en conexiones de fibra óptica.
Función:
Transformar la señal de la red interna a un formato adecuado para el medio del operador.
3.5 Medios de transmisión
Son los caminos por los que viajan los datos.
Pueden ser:
Cableados
Cable de par trenzado.
Cable coaxial.
Fibra óptica.
Inalámbricos
Wi-Fi.
Bluetooth.
Ondas de radio.
4. Topologías de red: la arquitectura de la conexión
La topología es la forma en la que se organizan físicamente o lógicamente los dispositivos de una red.
4.1 Topología en bus
Todos los equipos comparten un único cable central.
Ventajas:
Sencilla.
Económica.
Inconvenientes:
Si el cable principal falla, toda la red deja de funcionar.
Genera muchas colisiones.
Está obsoleta en entornos modernos.
4.2 Topología en anillo
Los dispositivos forman un círculo y la información circula en una dirección determinada.
Ventajas:
Flujo ordenado de la información.
Inconvenientes:
Si un equipo falla o se rompe el enlace, se interrumpe la comunicación.
Poco flexible.
4.3 Topología en estrella
Es la más utilizada actualmente.
Todos los dispositivos están conectados a un nodo central, normalmente un switch o router.
Ventajas:
Fácil de administrar.
Si falla un cable, solo se desconecta un equipo.
Permite ampliar la red con facilidad.
Inconveniente:
Si falla el dispositivo central, la red puede quedar afectada.
4.4 Topología en malla
Cada dispositivo está conectado a varios nodos, de forma que existen rutas alternativas.
Ventajas:
Alta redundancia.
Gran tolerancia a fallos.
Muy útil en redes críticas.
Inconvenientes:
Mayor coste.
Configuración más compleja.
5. El lenguaje de la red: protocolos de comunicación
Conectar dispositivos no es suficiente. Todos deben seguir unas normas comunes para entenderse. Esas normas reciben el nombre de protocolos.
La familia más importante hoy en día es TCP/IP, base del funcionamiento de Internet.
5.1 IP (Internet Protocol)
El protocolo IP identifica a cada dispositivo dentro de la red mediante una dirección IP.
Podemos imaginarla como una dirección postal que permite saber:
De dónde sale la información.
A dónde debe llegar.
5.2 TCP y UDP
Ambos son protocolos de transporte, pero funcionan de forma diferente.
TCP
Divide la información en partes.
Verifica que todo llegue correctamente.
Reordena los datos si es necesario.
Garantiza fiabilidad.
Usos habituales:
Navegación web.
Correo electrónico.
Transferencia de archivos.
UDP
Envía datos sin comprobar si han llegado.
Es más rápido.
Tiene menos sobrecarga.
Usos habituales:
Videollamadas.
Streaming en directo.
Videojuegos online.
5.3 DNS
El DNS traduce nombres de dominio comprensibles para las personas a direcciones IP comprensibles para las máquinas.
Ejemplo:
www.ejemplo.com → 142.250.190.14
Idea clave:
El DNS actúa como una agenda o guía telefónica de Internet.
5.4 DHCP
El DHCP asigna automáticamente una dirección IP a los dispositivos cuando se conectan a la red.
Gracias a ello, el usuario no tiene que configurar manualmente la IP de cada equipo.
5.5 HTTP y HTTPS
Son los protocolos utilizados para la navegación web.
HTTP
Permite intercambiar páginas web y otros recursos entre cliente y servidor.
HTTPS
Es la versión segura de HTTP. Añade cifrado para proteger la información intercambiada.
Ejemplo:
Cuando introduces contraseñas o datos bancarios en una web, lo correcto es que esa web utilice HTTPS.
6. El modelo OSI: entendiendo cómo viajan los datos
El modelo OSI (Open Systems Interconnection) es un modelo teórico que divide la comunicación de red en 7 capas.
Su objetivo es facilitar el estudio, diseño y resolución de problemas de red.
6.1 Capa 1: Física
Se encarga de transmitir bits a través del medio físico.
Ejemplos:
Cables.
Señales eléctricas.
Luz en fibra óptica.
Ondas Wi-Fi.
6.2 Capa 2: Enlace de datos
Agrupa bits en tramas, detecta errores locales y utiliza direcciones MAC.
Dispositivos relacionados:
Switches.
6.3 Capa 3: Red
Se encarga del direccionamiento lógico y del enrutamiento.
Elementos clave:
Direcciones IP.
Routers.
6.4 Capa 4: Transporte
Garantiza la entrega de la información entre origen y destino.
Protocolos principales:
TCP.
UDP.
6.5 Capa 5: Sesión
Controla el inicio, mantenimiento y cierre de la comunicación entre dos equipos.
6.6 Capa 6: Presentación
Se encarga de traducir, comprimir y cifrar los datos.
Ejemplos:
Codificación.
Compresión.
Cifrado.
6.7 Capa 7: Aplicación
Es la capa más cercana al usuario. Aquí trabajan las aplicaciones que utilizamos a diario.
Ejemplos:
Navegadores web.
Clientes de correo.
Aplicaciones de mensajería.
Servicios web.
7. Encapsulación: el viaje de los datos
Cuando un usuario envía un mensaje o solicita una página web, la información no viaja “tal cual”.
Pasa por un proceso llamado encapsulación:
Los datos se generan en la capa de aplicación.
Van descendiendo por las capas del modelo.
Cada capa añade su propia información de control.
Finalmente, los bits viajan por el medio físico.
En el equipo receptor ocurre lo contrario:
La información entra por la capa física.
Va subiendo capa a capa.
Cada nivel interpreta y elimina su parte de control.
La aplicación final muestra el contenido al usuario.
8. Relación entre dispositivos, protocolos y capas
Para entender mejor una red, conviene relacionar los conceptos vistos:
Switch → trabaja principalmente en la capa 2.
Router → trabaja principalmente en la capa 3.
TCP y UDP → pertenecen a la capa 4.
HTTP, HTTPS, DNS, DHCP → se usan en capas superiores, cercanas a la aplicación.
Cable, fibra, Wi-Fi → están relacionados con la capa 1.
9. Ejemplo real de comunicación en una red
Imagina que un alumno abre una página web desde el portátil del aula:
Escribe la dirección de la web en el navegador.
El equipo consulta al DNS para saber qué IP corresponde a ese nombre.
El portátil envía la petición a través del switch de la red local.
El router dirige la petición hacia Internet.
La información atraviesa varias redes hasta llegar al servidor web.
El servidor responde.
Los datos regresan al portátil.
El navegador interpreta la respuesta y muestra la página.
En este proceso intervienen dispositivos, protocolos, medios físicos y varias capas del modelo OSI.
Tabla comparativa: Modelo OSI vs Modelo TCP/IP
Modelo OSI
Función principal
Modelo TCP/IP
Función principal
7. Aplicación
Proporciona servicios de red a las aplicaciones del usuario
Aplicación
Reúne las funciones de aplicación, presentación y sesión
6. Presentación
Traduce, comprime y cifra los datos
Aplicación
Gestiona el formato de los datos y servicios de alto nivel
5. Sesión
Establece, mantiene y cierra sesiones de comunicación
Aplicación
Controla la comunicación entre aplicaciones
4. Transporte
Garantiza la entrega de datos extremo a extremo
Transporte
Gestiona la comunicación extremo a extremo mediante TCP o UDP
3. Red
Se encarga del direccionamiento lógico y del enrutamiento
Internet
Gestiona direcciones IP y el envío de paquetes entre redes
2. Enlace de datos
Controla acceso al medio, tramas y direcciones MAC
Acceso a la red
Maneja la transmisión local de datos sobre el medio físico
1. Física
Transmite bits por cables, radio o fibra
Acceso a la red
Incluye los medios físicos y el acceso al medio
Resumen rápido
Aspecto
Modelo OSI
Modelo TCP/IP
Número de capas
7 capas
4 capas
Origen
Modelo teórico de referencia
Modelo práctico usado en Internet
Nivel de detalle
Más detallado
Más simplificado
Uso real
Muy usado para enseñar y diagnosticar
Base real de las comunicaciones en red
Capas superiores
Aplicación, Presentación y Sesión separadas
Se agrupan en Aplicación
Capas inferiores
Enlace y Física separadas
Se agrupan en Acceso a la red
Relación entre ambos modelos
OSI
TCP/IP
Aplicación + Presentación + Sesión
Aplicación
Transporte
Transporte
Red
Internet
Enlace de datos + Física
Acceso a la red
10. Resumen del tema
Una red informática permite conectar dispositivos para compartir información y recursos.
Según su alcance, las redes pueden ser BAN, PAN, LAN, HAN, CAN, MAN, WAN o GAN.
Dentro de una red local encontramos elementos fundamentales como:
Hosts.
Switches.
Routers.
Módems / ONT.
Medios de transmisión.
Las redes también se pueden organizar según distintas topologías, siendo la estrella la más habitual hoy en día.
Para comunicarse, los dispositivos utilizan protocolos como:
IP
TCP
UDP
DNS
DHCP
HTTP
HTTPS
Además, el modelo OSI permite entender de forma ordenada cómo viajan los datos desde una aplicación hasta el medio físico y viceversa.
Importante Esta práctica está pensada para comprobar que el alumno tiene una base real en desarrollo web con PHP. No se busca una aplicación compleja. Se busca una aplicación simple, funcional, bien organizada y bien explicada.
¿Qué vais a hacer?
En esta práctica vais a desarrollar una pequeña aplicación web con:
una portada
una página con formulario
una página de listado
una base de datos MySQL
conexión con PHP usando mysqli
validación del formulario con JavaScript
Además del código, tendréis que entregar una documentación paso a paso explicando todo el proceso.
Objetivo de la práctica
El objetivo es construir una miniaplicación que permita registrar alumnos en una base de datos.
Cada registro deberá incluir como mínimo:
nombre
apellidos
email
curso
edad
La aplicación deberá permitir:
entrar en una portada,
acceder a un formulario,
validar los datos antes de enviarlos,
guardar esos datos en MySQL,
mostrar un listado con todos los registros guardados.
Qué debe tener la aplicación
Parte obligatoria
La aplicación debe incluir obligatoriamente:
una portada (index.php)
una página con formulario (formulario.php)
una página que procese el guardado (guardar.php)
una página de listado (listar.php)
una conexión a base de datos (conexion.php)
una validación con JavaScript (script.js)
una base de datos MySQL con una tabla
un archivo SQL con la creación de la base de datos y la tabla
Mejoras opcionales
Se valorará positivamente si añadís:
programación orientada a objetos
validación también en PHP
sesiones
login con contraseña
uso de password_hash()
consultas preparadas
edición de registros
borrado de registros
mejor diseño con CSS
Guía paso a paso
Paso 1. Crear la carpeta del proyecto
Cread una carpeta para guardar todos los archivos de la práctica.
Importante Aunque el proyecto sea pequeño, debéis mantener una estructura clara. Un proyecto desordenado suele dar problemas y también dificulta explicar el trabajo.
Paso 2. Crear la base de datos
Antes de empezar con PHP, debéis crear la base de datos y la tabla donde se guardarán los datos.
Script SQL de ejemplo
CREATE DATABASE practica_php; USE practica_php;CREATE TABLE alumnos ( id INT AUTO_INCREMENT PRIMARY KEY, nombre VARCHAR(50) NOT NULL, apellidos VARCHAR(100) NOT NULL, email VARCHAR(100) NOT NULL, curso VARCHAR(50) NOT NULL, edad INT NOT NULL );
Qué hace este script
crea una base de datos llamada practica_php
selecciona esa base de datos
crea una tabla llamada alumnos
define un campo id autoincremental
añade los campos del formulario
Qué debéis hacer vosotros
ejecutar el script
comprobar que la base de datos existe
comprobar que la tabla se ha creado correctamente
hacer una captura de pantalla
Ejemplo de explicación para la entrega
Primero he creado una base de datos llamada practica_php. Después he creado una tabla llamada alumnos, que servirá para almacenar los datos enviados desde el formulario. La tabla tiene un campo id como clave primaria y varios campos de texto y numéricos para guardar la información.
Paso 3. Crear la portada
La portada será la página inicial de la aplicación.
Debe incluir
un título
una breve descripción
un enlace al formulario
un enlace al listado
Ejemplo de index.php
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<title>Miniaplicación PHP</title>
<link rel="stylesheet" href="estilos.css">
</head>
<body>
<h1>Miniaplicación de registro de alumnos</h1>
<p>Esta aplicación permite guardar alumnos en una base de datos y mostrar su listado.</p>
<ul>
<li><a href="formulario.php">Ir al formulario</a></li>
<li><a href="listar.php">Ver listado</a></li>
</ul>
</body>
</html>
Qué debéis comprobar
la página carga sin errores
los enlaces funcionan
el texto se ve correctamente
Ejemplo de explicación para la entrega
He creado una portada en el archivo index.php para que la aplicación tenga una página inicial. En ella he añadido un título, una descripción breve y dos enlaces: uno al formulario y otro al listado.
Paso 4. Crear el formulario
Ahora debéis crear la página que permitirá introducir los datos.
action="guardar.php" indica a qué archivo se enviarán los datos
method="post" indica que los datos viajarán mediante POST
cada campo tiene name e id
el formulario tiene un id para poder validarlo con JavaScript
Importante Si un name está mal escrito, PHP no recibirá bien ese dato. Este es uno de los errores más comunes en este tipo de práctica.
Ejemplo de explicación para la entrega
En el archivo formulario.php he creado un formulario HTML con cinco campos. He usado el método POST para enviar los datos al archivo guardar.php, que será el encargado de procesarlos en PHP.
Paso 5. Validar el formulario con JavaScript
Antes de guardar los datos, debéis comprobar en el navegador que lo que el usuario ha escrito tiene sentido.
Debéis validar al menos
que no haya campos vacíos
que el email tenga formato válido
que la edad sea correcta
Ejemplo de script.js
document.addEventListener("DOMContentLoaded", function () {
const formulario = document.getElementById("formAlumno");
formulario.addEventListener("submit", function (e) {
const nombre = document.getElementById("nombre").value.trim();
const apellidos = document.getElementById("apellidos").value.trim();
const email = document.getElementById("email").value.trim();
const curso = document.getElementById("curso").value.trim();
const edad = document.getElementById("edad").value.trim();
if (nombre === "" || apellidos === "" || email === "" || curso === "" || edad === "") {
alert("Todos los campos son obligatorios.");
e.preventDefault();
return;
}
const patronEmail = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
if (!patronEmail.test(email)) {
alert("El email no tiene un formato válido.");
e.preventDefault();
return;
}
if (isNaN(edad) || edad < 1 || edad > 120) {
alert("La edad no es válida.");
e.preventDefault();
}
});
});
Qué debéis probar
dejar todos los campos vacíos
escribir un email incorrecto
escribir una edad no válida
rellenar todo correctamente
Ejemplo de explicación para la entrega
He creado un archivo script.js para validar el formulario antes del envío. Primero compruebo que no haya campos vacíos. Después reviso el formato del email mediante una expresión regular y, por último, valido que la edad sea numérica y esté en un rango lógico.
Importante La validación en JavaScript mejora la experiencia del usuario, pero no sustituye a la validación en servidor. Como mejora opcional, podéis validar también en PHP.
Paso 6. Crear la conexión a la base de datos
Ahora debéis preparar el archivo que conectará PHP con MySQL.
no hay errores de usuario, contraseña o nombre de base de datos
Ejemplo de explicación para la entrega
En conexion.php he definido las variables necesarias para conectarme a MySQL: servidor, usuario, contraseña y nombre de la base de datos. Después he usado new mysqli(...) para abrir la conexión y he añadido una comprobación para detectar errores.
Paso 7. Guardar los datos enviados
Aquí debéis recoger los datos del formulario y guardarlos en la tabla.
$_POST recoge los datos enviados por el formulario
INSERT INTO añade una fila nueva a la tabla
query() ejecuta la consulta SQL
si todo va bien, se muestra un mensaje de éxito
Ejemplo de explicación para la entrega
En guardar.php he recogido los valores enviados desde el formulario con $_POST. Después he creado una consulta INSERT para guardar esos datos en la tabla alumnos. Finalmente he ejecutado la consulta y he mostrado un mensaje de éxito si el guardado se ha realizado correctamente.
Importante Este ejemplo está hecho de forma simple para trabajar los fundamentos. Como mejora opcional, se valorará el uso de consultas preparadas.
Paso 8. Mostrar el listado de registros
Ahora debéis recuperar los datos de la tabla y mostrarlos en pantalla.
SELECT * FROM alumnos recupera todos los registros
query() ejecuta la consulta
fetch_assoc() devuelve una fila asociativa
el while recorre todas las filas
Ejemplo de explicación para la entrega
En listar.php he realizado una consulta SELECT para obtener todos los registros de la tabla alumnos. Después he usado un bucle while junto con fetch_assoc() para recorrer el resultado y mostrar cada alumno dentro de una tabla HTML.
Paso 9. Añadir un estilo básico
La parte visual no es lo principal, pero sí conviene que la aplicación tenga una presentación limpia.
He creado un archivo estilos.css para dar una presentación básica al proyecto. He aplicado una tipografía sencilla, un fondo claro y un estilo mínimo al formulario y a los campos de entrada.
Comprobaciones finales
Antes de entregar, revisad todo esto:
la portada carga correctamente
el formulario se muestra bien
la validación bloquea errores
los datos correctos se guardan
el listado muestra los registros
no hay enlaces rotos
la base de datos coincide con el código PHP
Qué debéis entregar
Debéis entregar un archivo comprimido .zip con esta estructura:
Que los archivos estén organizados y tengan sentido
Portada
Que exista, funcione y permita navegar
Formulario
Que tenga los campos pedidos y funcione
Validación JS
Que detecte errores básicos correctamente
Conexión con MySQL
Que use mysqli y funcione
Inserción de datos
Que los datos se guarden correctamente
Listado
Que se muestren todos los registros
Claridad del código
Que el código sea simple, comprensible y ordenado
Documentación
Que explique el proceso paso a paso
Mejoras opcionales
POO, sesiones, seguridad, edición, borrado, etc.
Plantilla completa de memoria para rellenar
A continuación tenéis una plantilla orientativa. Podéis seguir esta estructura para redactar vuestra memoria.
1. Portada
Título de la práctica: Miniaplicación web con PHP, MySQLi y JavaScript
Nombre y apellidos del alumno: [Escribir aquí]
Módulo: [Escribir aquí]
Fecha: [Escribir aquí]
2. Objetivo de la práctica
Ejemplo de redacción
El objetivo de esta práctica ha sido desarrollar una miniaplicación web en PHP conectada a una base de datos MySQL. La aplicación permite introducir datos de alumnos mediante un formulario, validarlos con JavaScript, guardarlos en la base de datos y mostrar posteriormente el listado de registros almacenados.
3. Descripción general del proyecto
Explicad qué archivos habéis creado y para qué sirve cada uno.
Ejemplo de redacción
El proyecto está compuesto por varios archivos. index.php actúa como portada. formulario.php contiene el formulario de entrada de datos. guardar.php procesa la información enviada y la guarda en la base de datos. listar.php muestra los registros. conexion.php establece la conexión con MySQL. script.js valida el formulario y estilos.css da formato básico a la aplicación.
4. Desarrollo paso a paso
4.1 Creación de la base de datos
Explicad:
el nombre de la base de datos
el nombre de la tabla
los campos creados
el script SQL utilizado
Ejemplo
Primero he creado una base de datos llamada practica_php. Después he creado una tabla llamada alumnos con un campo id autoincremental y cinco campos adicionales para almacenar nombre, apellidos, email, curso y edad.
4.2 Creación de la portada
Explicad:
qué contiene
por qué la habéis diseñado así
qué enlaces tiene
Ejemplo
He creado una página principal llamada index.php para que el usuario tenga un punto de entrada a la aplicación. En esta página he colocado un título, una breve descripción y enlaces al formulario y al listado.
4.3 Creación del formulario
Explicad:
qué campos tiene
qué tipo de datos se introducen
por qué habéis usado POST
Ejemplo
En formulario.php he añadido cinco campos: nombre, apellidos, email, curso y edad. He usado el método POST porque permite enviar los datos al servidor sin mostrarlos en la URL.
4.4 Validación con JavaScript
Explicad:
qué validaciones habéis hecho
qué errores queríais evitar
Ejemplo
He validado que los campos no estén vacíos, que el email tenga un formato correcto y que la edad sea un número válido. De este modo evito que lleguen a PHP datos claramente incorrectos.
4.5 Conexión con la base de datos
Explicad:
cómo funciona mysqli
qué datos necesita la conexión
cómo comprobáis errores
Ejemplo
Para conectar PHP con MySQL he usado mysqli. He indicado el servidor, el usuario, la contraseña y el nombre de la base de datos. Después he comprobado si la conexión producía algún error.
4.6 Guardado de datos
Explicad:
cómo llegan los datos a PHP
qué hace $_POST
qué consulta SQL habéis usado
Ejemplo
En guardar.php he recogido los datos enviados por el formulario con $_POST. Después he creado una consulta INSERT para guardar la información en la tabla alumnos.
4.7 Listado de registros
Explicad:
qué consulta habéis hecho
cómo se recorre el resultado
cómo se muestra en HTML
Ejemplo
En listar.php he usado una consulta SELECT * FROM alumnos para obtener todos los registros. Después he recorrido el resultado con fetch_assoc() dentro de un bucle while para mostrar cada alumno en una tabla HTML.
5. Capturas de pantalla
Debéis incluir capturas de:
base de datos creada
formulario en pantalla
error de validación
inserción correcta
listado funcionando
Ejemplo de cómo presentarlo
Captura 1. Creación de la base de datos [Insertar captura]
Captura 2. Formulario visible [Insertar captura]
Captura 3. Validación de campos vacíos [Insertar captura]
Captura 4. Registro guardado correctamente [Insertar captura]
Captura 5. Listado de alumnos [Insertar captura]
6. Pruebas realizadas
Aquí debéis explicar las pruebas que habéis hecho.
Ejemplo de redacción
He realizado varias pruebas para comprobar el funcionamiento de la aplicación. Primero he intentado enviar el formulario dejando campos vacíos, y la validación ha impedido el envío. Después he escrito un email incorrecto y también se ha bloqueado el formulario. Más tarde he introducido todos los datos correctamente y el registro se ha guardado en la base de datos. Finalmente he accedido a la página de listado y he comprobado que el alumno aparecía correctamente.
7. Problemas encontrados y soluciones
Esta parte es muy importante. No pongáis solo “ninguno” salvo que sea verdad de forma muy clara.
Ejemplo 1
Uno de los errores que encontré fue que PHP no recibía correctamente el valor del email. Revisando el formulario vi que el atributo name del campo no coincidía con la clave usada en $_POST. Después de corregirlo, el dato llegó correctamente.
Ejemplo 2
Al principio no se mostraban los registros en la tabla. El problema era que el nombre de la base de datos en conexion.php no coincidía con el creado en MySQL. Lo corregí y el listado empezó a funcionar.
8. Conclusión personal
Explicad qué habéis aprendido y qué os ha costado más.
Ejemplo de redacción
Con esta práctica he aprendido mejor cómo se conecta una aplicación PHP con una base de datos MySQL y cómo se relacionan el formulario, $_POST, el INSERT y el SELECT. La parte que más me costó fue comprender el flujo completo de datos desde el formulario hasta el listado, pero después de hacer varias pruebas lo entendí mejor.
Recomendaciones finales
Importante No intentéis hacer una aplicación enorme sin dominar primero lo básico. Es preferible una práctica sencilla, clara, funcionando bien y bien explicada, que una práctica más grande pero confusa.
Orden recomendado de trabajo
crear la base de datos
hacer la portada
hacer el formulario
validar con JavaScript
crear la conexión
guardar los datos
mostrar el listado
hacer capturas
redactar la memoria
Mejoras opcionales para subir nota
Si termináis la parte obligatoria, podéis añadir:
validación en servidor
clases en PHP
login
sesiones
consultas preparadas
edición de registros
borrado de registros
diseño visual mejorado
El objetivo real de esta práctica es que comprendáis el circuito básico de una aplicación web:
Una de las primeras cosas que hay que aprender en Linux es a moverse por el sistema de archivos y a trabajar con carpetas y archivos desde la terminal.
Aunque al principio pueda parecer extraño, aprender estos comandos es fundamental porque:
permite entender cómo está organizado Linux,
ayuda a trabajar con rapidez,
es imprescindible para administración de sistemas,
y será la base para tareas más avanzadas como configurar servicios, editar archivos de configuración, automatizar tareas o revisar logs.
En esta sesión vamos a centrarnos en:
comprender qué es una ruta,
movernos entre directorios,
listar contenido,
crear carpetas,
crear, copiar, mover y borrar archivos,
y entender buenas prácticas al trabajar en terminal.
1. ¿Qué es una ruta?
Una ruta es la dirección que indica dónde está un archivo o una carpeta dentro del sistema.
Linux organiza la información como un gran árbol que empieza en una raíz llamada:
/
Ese símbolo / representa el punto de partida del sistema de archivos.
Por ejemplo:
/home/alumno/documentos
indica que dentro de /home hay una carpeta llamada alumno, y dentro de ella una carpeta llamada documentos.
2. Rutas absolutas y rutas relativas
Ruta absoluta
Una ruta absoluta empieza siempre desde la raíz /.
Ejemplo:
/home/alumno/descargas
Da igual en qué carpeta te encuentres: esa ruta apunta siempre al mismo sitio.
Ruta relativa
Una ruta relativa parte desde la carpeta en la que estás en este momento.
Ejemplo:
Si estás en:
/home/alumno
y escribes:
cd documentos
Linux entiende que quieres ir a:
/home/alumno/documentos
3. Directorios especiales que debes conocer
En Linux hay algunos símbolos muy usados para trabajar con rutas:
.
Representa el directorio actual.
Ejemplo:
cd .
No cambia nada, porque te quedas donde estás.
..
Representa el directorio superior, es decir, la carpeta anterior.
Ejemplo:
cd ..
Sube un nivel.
~
Representa el directorio personal del usuario.
Por ejemplo, si tu usuario es alumno, ~ suele equivaler a:
/home/alumno
Ejemplo:
cd ~
Te lleva directamente a tu carpeta personal.
4. Comando pwd
¿Para qué sirve?
El comando pwd muestra la ruta completa de la carpeta en la que te encuentras.
pwd significa:
print working directory
Uso
pwd
Ejemplo de salida
/home/alumno
Cuándo usarlo
Es muy útil cuando:
no sabes en qué carpeta estás,
has navegado por varias rutas,
o quieres comprobar si un comando te ha llevado al lugar correcto.
5. Comando ls
¿Para qué sirve?
El comando ls muestra el contenido de una carpeta.
Uso básico
ls
Muestra archivos y carpetas del directorio actual.
Ejemplo
ls
Salida posible:
documentos descargas imagenes notas.txt
Variantes útiles
ls -l
Muestra la información en formato largo:
ls -l
Permite ver:
permisos,
propietario,
tamaño,
fecha,
nombre.
ls -a
Muestra también los archivos ocultos.
ls -a
En Linux, los archivos ocultos suelen empezar por punto, por ejemplo:
.bashrc
ls -la
Combina ambas opciones:
ls -la
Muy útil para administración y revisión completa del contenido.
6. Comando cd
¿Para qué sirve?
cd permite cambiar de directorio.
cd significa:
change directory
Ir a una carpeta dentro de la actual
cd documentos
Subir un nivel
cd ..
Ir al directorio personal
cd ~
o simplemente:
cd
Ir a una ruta absoluta
cd /var/log
Ejemplo práctico
Si estás en:
/home/alumno
y ejecutas:
cd documentos
pasarás a:
/home/alumno/documentos
Si después haces:
cd ..
volverás a:
/home/alumno
7. Crear directorios con mkdir
¿Para qué sirve?
Permite crear carpetas nuevas.
mkdir significa:
make directory
Crear una carpeta
mkdir pruebas
Crear varias carpetas a la vez
mkdir tema1 tema2 tema3
Crear una estructura completa de carpetas
mkdir -p curso/linux/comandos
La opción -p permite crear todos los niveles necesarios.
Sin -p, si alguna carpeta intermedia no existe, dará error.
8. Crear archivos
Hay varias formas de crear archivos en Linux.
Opción 1: touch
Crea un archivo vacío si no existe.
touch notas.txt
También puede usarse para actualizar la fecha de modificación de un archivo existente.
Opción 2: redirección
echo "Hola Linux" > saludo.txt
Esto crea el archivo y escribe contenido en él.
9. Ver contenido de archivos con cat
¿Para qué sirve?
Muestra el contenido de un archivo en pantalla.
cat saludo.txt
Salida:
Hola Linux
También puede mostrar varios archivos:
cat archivo1.txt archivo2.txt
10. Copiar archivos y carpetas con cp
Copiar un archivo
cp notas.txt copia_notas.txt
Copiar un archivo a otra carpeta
cp notas.txt documentos/
Copiar una carpeta completa
Para copiar directorios se usa -r:
cp -r proyecto proyecto_backup
La opción -r significa recursivo.
11. Mover y renombrar con mv
El comando mv sirve tanto para mover como para renombrar.
Renombrar un archivo
mv notas.txt apuntes.txt
Mover un archivo a otra carpeta
mv apuntes.txt documentos/
Mover una carpeta
mv proyecto /home/alumno/backup/
12. Borrar archivos y carpetas con rm y rmdir
Borrar un archivo
rm archivo.txt
Borrar una carpeta vacía
rmdir carpeta_vacia
Borrar una carpeta con contenido
rm -r carpeta
Mucho cuidado con rm
Este comando elimina contenido directamente. En terminal no hay papelera mágica que venga a salvarte del caos.
Especial cuidado con comandos como:
rm -r *
o peor aún, usar rm sin revisar bien la ruta.
Antes de borrar, conviene comprobar dónde estás con:
pwd
y qué hay dentro con:
ls
13. Comodines básicos
Linux permite usar comodines para trabajar con varios archivos a la vez.
*
Representa cualquier conjunto de caracteres.
Ejemplo:
ls *.txt
Muestra todos los archivos que terminen en .txt.
?
Representa un solo carácter.
Ejemplo:
ls archivo?.txt
Podría mostrar:
archivo1.txt
archivo2.txt
pero no archivo10.txt.
14. Nombres de archivos y carpetas: buenas prácticas
Aunque Linux permite muchos nombres distintos, conviene seguir ciertas reglas:
Recomendaciones
usar minúsculas,
evitar espacios,
usar guiones - o guiones bajos _,
usar nombres claros y descriptivos.
Bien
mis_apuntes.txt fotos_viaje backup-web
Mal
Mis Apuntes Definitivos Final FINAL.txt Carpeta Nueva 2
Los espacios pueden dar problemas o hacer más incómodo el trabajo en terminal.
15. Rutas con espacios
Si una carpeta tiene espacios en el nombre, la terminal interpreta cada palabra como algo separado.
Por ejemplo, esto fallará:
cd Mis documentos
Porque Linux intentará entrar en una carpeta llamada Mis y tomará documentos como otro argumento.
echo "Primera práctica de Linux" > documentos/notas.txt
Paso 11: leer el archivo
cat documentos/notas.txt
17. Resumen de comandos básicos
Comando
Función
pwd
Muestra la ruta actual
ls
Lista archivos y carpetas
ls -l
Lista con detalle
ls -a
Muestra ocultos
cd ruta
Cambia de directorio
cd ..
Sube un nivel
cd ~
Va al directorio personal
mkdir nombre
Crea una carpeta
mkdir -p ruta
Crea carpetas anidadas
touch archivo
Crea un archivo vacío
cat archivo
Muestra el contenido
cp origen destino
Copia archivos o carpetas
mv origen destino
Mueve o renombra
rm archivo
Borra archivo
rm -r carpeta
Borra carpeta con contenido
rmdir carpeta
Borra carpeta vacía
18. Errores habituales
1. Confundir archivo y carpeta
Intentar hacer:
cd archivo.txt
Pero cd solo sirve para entrar en directorios, no en archivos.
2. No saber en qué carpeta están
Empiezar a ejecutar comandos sin comprobar la ubicación actual.
Solución:
pwd
3. Borrar sin revisar
Usar rm demasiado rápido y luego llega el drama informático.
Antes de borrar:
pwd ls
4. Escribir mal una ruta
Por ejemplo:
cd /home/alumno/documento
cuando la carpeta real es documentos.
Linux distingue exactamente los nombres.
5. Problemas con espacios
Escribir:
cd Mis documentos
cuando deberían usar comillas o barra invertida.
19. Actividad práctica
Practicar navegación por rutas, creación de carpetas, creación de archivos, copia, movimiento y borrado.
Enunciado
Realiza en terminal las siguientes tareas:
Comprueba en qué directorio te encuentras.
Crea una carpeta llamada practica_rutas.
Entra en ella.
Crea dentro tres carpetas:
documentos
imagenes
backup
Crea dentro de documentos los archivos:
notas.txt
ejercicios.txt
Escribe una línea de texto dentro de notas.txt.
Muestra por pantalla el contenido de notas.txt.
Copia notas.txt dentro de backup.
Renombra ejercicios.txt a ejercicios_linux.txt.
Vuelve al directorio anterior.
Lista el contenido con detalle.
Elimina la carpeta imagenes.
Comprueba el resultado final.
Posible solución de la actividad
pwd mkdir practica_rutas cd practica_rutas mkdir documentos imagenes backup touch documentos/notas.txt documentos/ejercicios.txt echo "Estoy aprendiendo comandos en Linux" > documentos/notas.txt cat documentos/notas.txt cp documentos/notas.txt backup/ mv documentos/ejercicios.txt documentos/ejercicios_linux.txt cd .. ls -l rmdir practica_rutas/imagenes ls practica_rutas
Ejercicios adicionales
Ejercicio 1
Crea la siguiente estructura:
linux_practica/ ├── tema1/ ├── tema2/ └── tema3/
Ejercicio 2
Dentro de tema1, crea tres archivos:
apuntes.txt
comandos.txt
resumen.txt
Ejercicio 3
Copia comandos.txt a tema2.
Ejercicio 4
Renombra resumen.txt a resumen_final.txt.
Ejercicio 5
Elimina tema3.
Chuleta
pwd # ver en qué carpeta estoy ls # listar contenido ls -la # listar con detalle y ocultos cd nombre_carpeta # entrar en carpeta cd .. # subir un nivel cd ~ # ir a mi carpeta personal mkdir carpeta # crear carpeta mkdir -p a/b/c # crear varias carpetas anidadas touch archivo.txt # crear archivo vacío cat archivo.txt # ver contenido cp origen destino # copiar mv origen destino # mover o renombrar rm archivo.txt # borrar archivo rmdir carpeta # borrar carpeta vacía rm -r carpeta # borrar carpeta con contenido
![[Reto] – Miniaplicación web con PHP, MySQLi y JavaScript (Sin POO)](https://laaventuradeaprender.com/wp-content/uploads/2026/03/0406ee2c-f553-451d-8d19-8fed5738a401-1.png)
