Teoría General de Sistemas · ADSO

Bienvenido al mundo del software.
Tu código es parte de un sistema mayor.

Cuando aprendes a programar, parece que lo más difícil es que el código compile. Pero pronto descubrirás que el verdadero reto es mantener un conjunto de partes (archivos, bases de datos, servidores) trabajando juntas sin que el desorden lo destruya. Esta guía te explica de forma sencilla qué es un sistema y por qué tu software falla cuando crece.

Ola 1 · control Ola 2 · sistemas abiertos Ola 3 · complejidad mapa evolutivo ejercicios micro-reto
~/tgs — resumen de la guía
01$ tgs --explain "arquitectura moderna"
02iniciando lección para ADSO … ok
03cargando conceptos básicos … ok
04mapeando olas → eras de software … ok
05 
06tesis = {
07  "un solo archivo": // es un desastre cuando crece
08  "frontend y backend": // separan responsabilidades
09  "la pieza final": // resuelve lo que no puedes programar
10}
11 
12⚠ el software nunca está aislado. Siempre es un sistema.
14$

Fase 01 · Reflexión

Los problemas ocultos del software.
¿Por qué el código se rompe?

Como aprendiz, seguro has notado que arreglar un error a veces crea tres errores nuevos. Estos no son fallos de tu lógica, son propiedades de los sistemas. Selecciona los síntomas que hayas vivido al programar para descubrir qué propiedad sistémica los está causando.

diagnóstico-sistémico.exec local · sin envío de datos

sin selección

Selecciona al menos un síntoma. El diagnóstico no evalúa tu código: nombra la propiedad del sistema que lo está produciendo.

// {{ results.length }} PATRÓN(ES) SISTÉMICO(S) IDENTIFICADO(S)

{{ waveName(d.wave) }}

{{ d.title }}

{{ d.text }}

{{ d.lever }}

Reflexión

Reconocer que los errores en tu código a menudo son problemas de organización, no de lógica.

Contextualización

Conocer cómo ha evolucionado la forma de crear software desde los años 50 hasta la Inteligencia Artificial.

Apropiación

Entender los conceptos básicos jugando con simuladores y respondiendo preguntas sencillas.

Transferencia

Identificar las partes de una aplicación web real (Frontend, Backend, Base de Datos).

Fase 02 · Contextualización

Fundamentos del software como sistema

Antes de que existieran las computadoras modernas, los científicos ya estudiaban cómo funcionan los sistemas complejos. La Teoría General de Sistemas (TGS) descubrió reglas universales que rigen todo: desde una célula hasta una ciudad. En el software, la TGS explica por qué el código se vuelve inmanejable cuando crece y por qué tuvimos que evolucionar hacia la Inteligencia Artificial para sobrevivir a la complejidad.

definición operativa

Un sistema son las relaciones

Un sistema es un grupo de partes conectadas. En programación, si tienes HTML, CSS y JavaScript sueltos, tienes archivos. Cuando los conectas para que interactúen, tienes una aplicación. La conexión lo es todo.

propiedad clave

El todo no es la suma

Puedes tener un formulario HTML perfecto y una base de datos bien diseñada. Pero si el código que los une falla, la aplicación completa está rota. El comportamiento global depende de cómo se comunican las partes.

consecuencia

Cuidado al cambiar cosas

A veces, al intentar "mejorar" una función, rompemos otra que dependía de ella. En un sistema, no puedes modificar una pieza importante sin pensar en cómo afectará al resto del código.

El problema de crecer

Tu código debe estar preparado para el mundo real. A medida que un programa se vuelve más útil, los usuarios harán cosas más inesperadas. Si tu código solo espera comportamientos perfectos, fallará.

Esta es la razón por la que la programación moderna usa Inteligencia Artificial y múltiples capas de seguridad. A veces, hay tantos posibles errores que no puedes programar "if" para todos ellos. Necesitas sistemas que sepan adaptarse solos.

Diccionario TGS para el Desarrollador

No hablemos de biología ni termostatos. Traduzcamos los principios de la Teoría General de Sistemas directamente a tu trabajo diario:

Frontera del Sistema

La línea de defensa. En código, es tu API y tus validaciones (ej. if(edad < 0) error). Todo lo que entra debe ser filtrado; si no defines fronteras fuertes, datos corruptos destruirán la base de datos.

Entropía y Negentropía

Entropía es la tendencia natural del código a volverse espagueti (desorden) por parches rápidos. La Negentropía es el tiempo que inviertes refactorizando para limpiar ese desorden antes de que sea fatal.

Homeostasis

Mantenerse vivo ante el estrés. En software se llama Tolerancia a fallos o Auto-escalado. Si 10,000 usuarios entran de golpe, el sistema prende más servidores o rechaza conexiones ordenadamente para no colapsar.

Ley de Variedad Requerida

"Sólo la variedad destruye variedad" (Ashby). Si tus usuarios tienen infinitas formas de equivocarse, 100 condicionales (IFs) no bastarán. Necesitas un regulador con igual variedad: La Inteligencia Artificial.

Equifinalidad

Varios caminos llevan al mismo resultado. En desarrollo backend esto se llama Idempotencia: Si la red falla y envías el pago 3 veces, el sistema inteligente cobra solo una vez, asegurando un estado final correcto sin importar el camino torpe.

Emergencia

El sistema entero hace cosas que las partes sueltas no pueden. A veces es genial (un modelo de IA que empieza a "razonar"), a veces es una pesadilla (un bug crítico que solo ocurre cuando API, Base de Datos y Red interactúan a cierta hora).

{{ current.id }}/tesis.md {{ current.metric }}

{{ current.thesis }}

Concepto núcleo
{{ current.core }}
Qué regula
{{ current.regulates }}
Analogía de ingeniería
{{ current.analogy }}
Modo de fallo característico
{{ current.failure }}
Huella en software
{{ current.software }}
Referencias
{{ current.authors }}
{{ current.code.caption }}

              
¿Por qué el código se vuelve feo con el tiempo?

A esto se le llama "entropía". Es la tendencia natural del código a volverse un desorden si solo agregas cosas sin limpiar. Si un grupo de aprendices trabaja en el mismo archivo añadiendo funciones a la carrera, pronto nadie entenderá el archivo.

Para combatir esto existe la "Refactorización". Consiste en reescribir y limpiar el código (sin cambiar lo que hace) para mantenerlo ordenado. Ordenar cuesta esfuerzo, pero si no lo haces, el proyecto terminará siendo imposible de modificar.

Separar tu proyecto en Frontend, Backend y Base de Datos es la principal forma de mantener el orden y evitar este caos.

De programar reglas a entrenar IA

En la programación tradicional, tú le dices a la computadora exactamente qué hacer paso a paso: "si pasa esto, haz aquello".

Pero algunas tareas son muy complejas para reglas estrictas, como reconocer la voz o recomendar películas. Aquí entra la Inteligencia Artificial. En lugar de darle reglas estrictas, le damos ejemplos y dejamos que aprenda patrones por sí sola.

Hoy en día, las aplicaciones combinan ambas cosas: reglas estrictas para lo seguro (como guardar una contraseña) e IA para lo complejo (como detectar si un correo es spam).

Fase 02 · Contextualización

La evolución del desarrollo de software · el camino hacia la IA

Aprende cómo hemos pasado de escribir todo en un solo archivo a usar aplicaciones divididas y, finalmente, a usar Inteligencia Artificial para resolver problemas que el código no puede.

mapa-evolutivo.svg — TGS ↔ arquitectura infografía generativa
Ola 1 Ola 2 Ola 3

// usa las flechas ← → para recorrer las eras cuando el mapa tenga el foco

Las cuatro fases de la programación

Fase 1 · Todo en uno

El "Monolito" (Un solo archivo/proyecto gigante)

Es como hacer un sitio web poniendo el HTML, CSS, JavaScript y las conexiones a base de datos en el mismo archivo `index.php` gigante. Es fácil empezar, pero imposible de mantener.

El problema: Código espagueti. Cambiar el color de un botón rompe el formulario de registro. Nadie quiere tocar el código por miedo a romperlo todo.

Fase 2 · Separación de responsabilidades

Frontend y Backend (Arquitectura dividida)

Los desarrolladores entendieron que había que separar las cosas. Ahora tenemos una carpeta para la vista (HTML/CSS) y otra para el servidor (PHP/Node.js). Se comunican a través de peticiones.

El problema: Conexiones lentas o caídas. Si el Backend se apaga, el Frontend muestra una pantalla en blanco. Hay que programar qué hacer si la red falla (usar try/catch).

Fase 3 · Sistemas que se cuidan a sí mismos

Aplicaciones en la Nube

Ya no es solo Frontend y Backend, ahora las aplicaciones corren en servidores que se reinician solos si fallan (como Docker o servicios de AWS). Si hay muchos usuarios, se clonan automáticamente para no colapsar.

El problema: Demasiadas cosas moviéndose al mismo tiempo. Es muy difícil rastrear un error porque cuando sucede, el servidor que falló ya fue destruido y reemplazado por uno nuevo.

Fase 4 · El salto de la IA

Inteligencia Artificial

Cuando los usuarios empezaron a subir fotos y pedir respuestas "en lenguaje humano", los programadores no podían escribir "if/else" para cada palabra o píxel. La solución: usar algoritmos que aprenden en lugar de algoritmos que siguen órdenes ciegas.

El cambio clave: En lugar de programar la solución al problema paso a paso, programas a una IA para que ella misma descubra la solución viendo ejemplos.

Correspondencia entre principios de la Teoría General de Sistemas y prácticas de ingeniería de software
Principio TGS Traducción en ingeniería Artefacto concreto Síntoma si falta
Frontera del sistema Interfaz pública, propiedad del dato, política de admisión API versionada, esquema, validación de entrada Cambiar un servicio rompe otro que no lo llama
Cohesión / acoplamiento Un módulo, un propósito; una dependencia, un contrato Contexto delimitado, prueba de contrato Despliegues coordinados entre varios equipos
Retroalimentación negativa Medir, comparar con un objetivo y corregir SLO + escalado automático + cortacircuito La corrección depende de que alguien esté despierto
Homeostasis Mantener variables clave en rango ante perturbaciones Presupuesto de error, autorreparación, cuotas Cada pico de tráfico es un incidente
Entropía / negentropía Reducir ambigüedad estructural con trabajo explícito Refactorización, tipos, esquema único de datos Tres formatos para el mismo dato y ninguno autoritativo
Variedad requerida El regulador debe igualar la variedad del entorno Reglas declarativas, tablas de decisión, modelos Funciones con decenas de condicionales acumulados
Emergencia El comportamiento global no se deduce de las partes Observabilidad distribuida, ingeniería del caos Incidentes que ninguna prueba unitaria anticipó
Equifinalidad Varios caminos válidos hacia el mismo estado final Consistencia eventual, idempotencia, reintento seguro El sistema exige un único orden de eventos para ser correcto

Fase 04 · El salto a la Inteligencia Artificial

¿Por qué dejamos de programar TODO a mano?

En la programación clásica, tú controlas todo. Si algo falla, sabes exactamente en qué línea de código fue. ¿Por qué cambiaríamos eso por IA que "adivina"? Porque no teníamos otra opción frente a estos tres problemas del mundo real.

presión 1

Explosión combinatoria de la variedad

Detectar fraude con reglas explícitas exige enumerar los patrones del atacante. El atacante genera patrones nuevos más rápido de lo que tú los escribes. La carrera está perdida por estructura, no por talento: tu regulador crece linealmente y su variedad crece combinatoriamente.

presión 2

Entropía de los datos masivos

Texto libre, imágenes, audio y clics no tienen esquema. Son entropía en estado puro para un sistema determinista. No hay `if` que lea una foto. La única forma de extraer orden de esa masa es un proceso que aprenda la estructura en vez de recibirla especificada.

presión 3

Capacidad de cómputo por fin disponible

La retropropagación se popularizó en 1986; el descenso de gradiente es anterior. Faltaba la energía. El cómputo masivamente paralelo hizo económicamente viable pagar el precio negentrópico de ordenar millones de parámetros. La teoría esperó tres décadas a la termodinámica.

El intercambio, dicho sin adornos

Al pasar a lo probabilístico ganas capacidad de absorber variedad no especificable y pierdes derivabilidad causal. Un sistema determinista falla de forma reproducible; uno probabilístico falla con una distribución. Esto no es un defecto de implementación que se arregle con mejores modelos: es una propiedad del tipo de sistema. La respuesta arquitectónica correcta no es confiar más, es envolver el subsistema probabilístico en fronteras y verificadores deterministas. Ese es exactamente el objetivo del micro-reto al final de la guía.

Fase 03 · Apropiación

Desmitificando la IA · Es solo software que aprende

Una Inteligencia Artificial como ChatGPT parece magia, pero en el fondo es solo un programa. La diferencia es que usa ciclos para corregir sus propios errores y mejorar. Veamos cómo lo hace usando conceptos de programación que ya conoces.

retropropagación = lazo cibernético

Wiener definió el control como un ciclo de cuatro piezas. La retropropagación las implementa todas, sin excepción y sin metáfora:

Planta (el sistema controlado)
La red: pesos, sesgos y no linealidades.
Sensor
La función de pérdida. Convierte «qué tan mal va» en un número comparable.
Comparador
El gradiente ∇L: dirección y magnitud de la desviación respecto al objetivo.
Actuador
La actualización θ ← θ − η∇L. Corrige la planta en proporción al error.

La diferencia con un termostato es de orden, no de naturaleza: el termostato ajusta una variable, la red ajusta su propia función de transferencia. Eso es cibernética de segundo orden — un sistema que modifica sus propias reglas de operación.

el lazo completo, en seis líneas
for epoch in range(N):
    y_hat = red.forward(x)          # la planta produce salida
    L     = perdida(y_hat, y)        # SENSOR: mide la desviación
    g     = red.backward(L)          # COMPARADOR: hacia dónde corregir
    theta = theta - eta * g          # ACTUADOR: corrige la planta
    # el lazo se repite: retroalimentación NEGATIVA pura
entrenar = comprar orden con energía

La función de pérdida más usada en clasificación se llama entropía cruzada, y el nombre es literal: mide, en bits, cuánta incertidumbre queda entre la distribución que predice el modelo y la distribución real de los datos.

Entrenar es minimizar esa cantidad. Es decir: entrenar es un proceso negentrópico. El modelo pasa de un estado de máxima incertidumbre —pesos aleatorios, salida uniforme— a un estado de baja entropía en el que su distribución interna reproduce la estructura del entorno.

Y la segunda ley sigue intacta

El orden local se paga exportando desorden al entorno: calor, consumo eléctrico, depreciación del hardware. Un centro de datos entrenando es una estructura disipativa en el sentido exacto de Prigogine: mantiene orden interno gracias a un flujo continuo de energía que degrada. Es el mismo argumento con el que Schrödinger explicó la vida.

De ahí se deduce algo operativo: si dejas de alimentar el lazo —datos frescos, reentrenamiento, evaluación— la entropía del entorno vuelve a ganar. Eso tiene nombre propio en producción: deriva del modelo. No es que el modelo se degrade; es que el entorno se movió y el sistema dejó de ser abierto.

emergencia en modelos de lenguaje

La unidad de un modelo de lenguaje es aritmética elemental: una suma ponderada seguida de una no linealidad. No hay gramática codificada, ni base de conocimiento, ni motor de inferencia lógica. Y sin embargo, al escalar el número de elementos y la densidad de sus interacciones, aparecen capacidades que nadie especificó: traducción, seguimiento de instrucciones, aprendizaje en contexto, razonamiento por pasos.

Eso es emergencia en el sentido estricto de la Ola 3: propiedades del conjunto ausentes en cada parte y no deducibles de ellas por composición simple.

El mecanismo de atención merece una lectura sistémica propia: define qué elementos se acoplan con cuáles en cada paso y según el contenido. Es acoplamiento dinámico — la topología interna del sistema deja de ser fija y pasa a ser una variable de estado. Autoorganización topológica, no una metáfora de ella.

Honestidad técnica

Existe un debate serio sobre si ciertas «capacidades emergentes» aparecen de forma realmente abrupta. Schaeffer, Miranda y Koyejo (2023) mostraron que varias de esas curvas en escalón se suavizan al cambiar métricas discontinuas por métricas continuas: parte del salto estaría en el instrumento de medición, no en el sistema. El punto sistémico sobrevive al debate: la capacidad no está escrita en ninguna parte del modelo. Lo que se discute es la forma de la curva, no la ausencia de especificación.

perillas de entropía y modos de fallo
Temperatura
Control directo de la entropía del muestreo. Cerca de 0 el sistema es casi determinista y repetitivo; alta, explora más y se desordena. Es una perilla sistémica, no estética: decides cuánta variedad admites en la salida.
Ventana de contexto
La frontera perceptiva del sistema. Todo lo que queda fuera, sencillamente no existe para él. Muchos fallos atribuidos al «modelo» son fallos de diseño de esa frontera.
Recuperación y herramientas
Sensores hacia el entorno. Convierten un sistema cerrado —que sólo consulta su estado interno— en un sistema abierto capaz de corregirse con información externa.

La alucinación, en términos de sistemas

No es un defecto de codificación. Es un fallo de frontera y de sensado: el sistema genera una continuación coherente con su estado interno y no dispone de ningún canal que le informe que el entorno dice otra cosa. Sin sensor externo no hay señal de error; sin señal de error no hay corrección posible. El lazo está abierto.

Por eso la mitigación es arquitectónica, no conversacional: recuperación de fuentes, llamadas a herramientas, verificadores deterministas y esquemas de salida. Se le construye al sistema el sensor que le falta.

Fase 03 · Apropiación · Ejercicios

Desafíos prácticos

Antes de pasar al simulador, pongamos a prueba lo que aprendiste sobre Fronteras, Entropía e Inteligencia Artificial.

{{ ex.title }}

{{ ex.scenario }}

{{ answered[i] === ex.correctIndex ? ex.feedbackGood : ex.feedbackBad }}

Fase 03 · Apropiación · caja de arena

Simulador: Entrenando una Inteligencia Artificial

Aquí tienes una IA real aprendiendo en tu navegador. Su objetivo es separar los puntos naranjas de los azules. Observa cómo aprende por ensayo y error (un lazo cerrado). Juega con la dificultad, desconecta su capacidad de aprender o lánzale datos basura para ver cómo el sistema intenta recuperar el equilibrio.

ia.sandbox — panel de control interactivo en reposo
frontera de decisión · espacio de entrada
intentos0
error (pérdida)
aciertos (%)
corrección
conexiones · "cerebro" de la ia
disminución del error en el tiempo

La espiral es muy compleja. Si la IA no tiene suficientes "Neuronas", jamás podrá resolverla, sin importar cuánto tiempo la dejes entrenando.

Tamaño del Cerebro (Neuronas)6

Más neuronas le dan más poder a la IA para entender problemas complejos (mayor variedad).

Velocidad de Aprendizaje0,14

Baja: aprende seguro pero muy lento. Alta: intenta aprender tan rápido que se "salta" la respuesta correcta y se vuelve inestable.

Datos Basura (Ruido)0,10

Desordena los puntos a propósito. Demasiado ruido hace imposible que la IA encuentre un patrón claro.

Si lo apagas, la IA se vuelve "sorda" y no puede corregir sus equivocaciones. Un software sin avisos de error (logs/try-catch) es igual.

Desordena la memoria de la IA de un solo golpe. Si "Aprender de los errores" está activo, la IA se recuperará. Si está apagado, quedará rota para siempre.

experimento 1

Aprender demasiado rápido

Sube la "Velocidad de Aprendizaje" al máximo. Verás que la gráfica de error salta por todos lados. Si intentas arreglar un error en tu código web a lo loco sin pensar, solo generarás más errores.

experimento 2

Volar a ciegas (Lazo abierto)

Espera a que el error baje casi a cero. Luego, APAGA "Aprender de los errores" y presiona "Generar Caos Repentino". El error subirá y nunca bajará. Un sistema que no revisa sus errores está condenado a romperse.

experimento 3

Cerebro muy pequeño

Elige "Espiral" (Difícil) y baja el tamaño del cerebro a 2 Neuronas. Por más intentos que haga, nunca resolverá el problema. Problemas complejos requieren herramientas (o códigos) con capacidad de manejar alta variedad.

Fase 04 · Arquitecturas de próxima generación

Agentes Inteligentes · la IA como guardián de tu código

El uso más interesante de la IA en la programación web no es generar código. Es usar la IA como un Agente Autónomo: un programa capaz de leer los errores de un servidor, decidir cómo arreglarlos (por ejemplo, reiniciar la base de datos) y actuar por sí mismo para mantener tu aplicación viva.

lazo-agéntico.md — un termostato con un LLM adentro

Un agente bien diseñado no es solo "un chat de IA". Es un ciclo continuo (lazo) que le da a la IA manos y ojos para interactuar con tu servidor. Sus 5 pasos son:

1 · Leer (Sensar)
La IA revisa los logs de errores o el tráfico del servidor.
2 · Comparar
Revisa si la web está funcionando bien o si está lenta y a punto de caerse.
3 · Pensar (Decidir)
La IA analiza el error y busca la mejor solución posible.
4 · Actuar
Se le da permiso para ejecutar comandos: reiniciar un servicio o avisar a un humano.
5 · Verificar
Revisa si su acción arregló el problema. Si no, intenta de nuevo o se detiene.
bot-guardian · código simplificado de un Agente
async function cicloDelAgente(servidor, reglas) {
  while (reglas.activo()) {
    const estado = await servidor.leerLogs();         // 1 leer
    const error = desviacion(estado, politica.slo);   // 2 comparador
    if (error.magnitud < politica.histeresis) continue;

    const plan = await agente.decidir(estado, error);  // 3 alta variedad

    // FRONTERA: el plan es una propuesta, no una orden.
    if (!validarEsquema(plan)) { rechazar(plan); continue; }
    if (!politica.permite(plan.accion)) { escalarAHumano(plan); continue; }
    if (presupuesto.agotado()) { abrirLazo("límite de gasto"); break; }

    await sistema.actuar(plan.accion);                // 4 actuador
    await esperar(politica.retardoDelSensor);        // evita oscilación
    const despues = await sistema.sensar();       // 5 verificar

    if (empeoro(despues, estado)) {
      await sistema.revertir(plan);
      abrirLazo("la corrección amplificó el error");   // interruptor
    }
  }
}

Peligros de dejarle el servidor a una IA

El Bot se vuelve loco

La IA intenta arreglar un error, pero su propia acción causa un error peor. Al intentarlo de nuevo, destruye el servidor (bucle infinito).

Solución: Limitar cuántas acciones seguidas puede hacer.

Reacción tardía

La IA lee un error de hace 5 minutos, intenta arreglarlo ahora, pero el problema ya había pasado. Termina dañando algo que estaba bien.

Solución: Asegurarse de que lea datos en tiempo real.

IA con demasiado poder

Le diste permisos de administrador a la IA "para que haga todo". Una mala decisión de la IA borra toda la base de datos de usuarios.

Solución: Privilegio mínimo (solo darle permiso para reiniciar servicios).

Reglas oxidadas

Actualizaste tu página web, pero no le avisaste a la IA. La IA sigue intentando arreglar errores usando las reglas de la versión vieja.

Solución: Revisión constante de las instrucciones del Agente.

El Humano siempre es el jefe

Nunca dejes que un Agente IA tome decisiones destructivas por sí solo (como borrar una base de datos o hacer un cobro a un cliente). Las acciones irreversibles siempre deben detenerse y preguntarle a un programador humano: "¿Apruebas esta acción?". La IA sugiere y repara lo rápido; el humano toma las decisiones críticas.

Fase 04 · Transferencia

Micro-reto Arquitectónico · arma tu primera app web

Ocho zonas de tu servidor están vacías. Tienes una lista de componentes (Frontend, Backend, Base de Datos, IA, etc.). Arrastra el componente correcto a su zona correspondiente. ¡Cuidado con las trampas comunes de los novatos!

arquitectura-resiliente.lab 0 / 8 zonas

Componentes disponibles

// arrastra, o selecciona y luego pulsa una zona

evaluación por principios sistémicos

// el acta se produce localmente en tu navegador; no se envía a ningún servidor

Criterio de transferencia

Llévate esta pregunta a tu proyecto real, no al ejercicio: ¿dónde está la frontera, dónde está el sensor, dónde está el actuador y qué abre el lazo cuando la corrección empeora las cosas? Una arquitectura que no puede responder esas cuatro preguntas no es resiliente; simplemente todavía no ha sido perturbada lo suficiente.

Fase 03 · Apropiación · verificación

Verificación conceptual

Ocho preguntas de criterio. Cada respuesta muestra el razonamiento sistémico completo, acertada o no: el objetivo es el modelo mental, no la puntuación.

{{ String(i + 1).padStart(2, '0') }}{{ q.q }}

{{ answered[i] === q.a ? 'Correcto.' : 'Revisemos.' }} {{ q.why }}

resultado.log

{{ score }} / {{ quiz.length }}  criterios sistémicos correctos

{{ feedback }}

Referencia

Glosario operativo

Vocabulario mínimo para discutir arquitectura en términos de sistemas. Cada término está redactado para ser usado en una revisión de diseño, no para ser memorizado.

// {{ filtered.length }} de {{ items.length }} términos

{{ g.t }} · {{ g.e }}

{{ g.d }}

Sin coincidencias para «{{ q }}».