El nombre de tu facultad no es casualidad. Esta es la disciplina profesional que todo lo visto en TGS hace posible.
👁 — vistas · Usa las flechas ← → , el teclado o desliza para navegar
Introducción
En TGS Aplicada: Sistemas de Información como Sistemas viste, de pasada, que el programa Apolo de la NASA popularizó la disciplina de "Ingeniería de Sistemas" a gran escala.
Esta presentación retoma esa mención y la desarrolla por completo: no como una anécdota, sino como la profesión para la que te estás formando.
Introducción
Esta presentación da por sabido lo visto en TGS Aplicada: Sistemas de Información como Sistemas (límite, entorno, subsistemas, entrada-proceso-salida) y en Metodologías de Sistemas: Duros y Blandos (SSM) (definiciones raíz y CATWOE). No los vuelve a explicar: los usa directamente como herramientas de trabajo.
Introducción
Sección 1
1 · Origen de la disciplina
El término "systems engineering" se usó formalmente por primera vez en Bell Telephone Laboratories, en la década de 1940, para gestionar sistemas de telecomunicaciones demasiado grandes y complejos como para diseñarlos pieza por pieza. Tres décadas después, el programa Apolo la llevó a otra escala. En 1990 se fundó el INCOSE, que hoy publica el Systems Engineering Handbook, la referencia mundial de la profesión.
1 · Origen de la disciplina
La Ingeniería de Software se concentra en construir código: aplicaciones, servicios, algoritmos. La Ingeniería de Sistemas mira más arriba en la jerarquía que ya conocés de TGS: coordina el sistema completo —hardware, software, personas, procesos e interfaces entre todos ellos— para que, en conjunto, cumplan un propósito.
El nombre de tu facultad es intencional: te prepara para ver más allá del código, hacia el sistema completo del que ese código es apenas un subsistema.
1 · Origen de la disciplina
Un hospital digitaliza su historia clínica. El proyecto incluye escribir el software, comprar tablets para el personal médico, rediseñar el proceso de admisión de pacientes, y capacitar al personal para usar el nuevo flujo. ¿Qué disciplina describe mejor la coordinación de todo ese proyecto, y no solo del código?
Sección 2
2 · El ciclo de vida en V
El lado izquierdo define el sistema con detalle creciente, el vértice es la implementación, y el lado derecho verifica cada nivel, de abajo hacia arriba — cada etapa contra su pareja de definición.
2 · El ciclo de vida en V
| Etapa de definición (baja) | Su pareja de verificación (sube) |
|---|---|
| Requisitos: qué debe lograr el sistema, y para quién. | Validación: ¿el sistema terminado satisface la necesidad original? |
| Arquitectura: cómo se divide el sistema en subsistemas. | Verificación de integración: ¿los subsistemas funcionan juntos? |
| Diseño detallado: cómo se construye cada componente. | Pruebas de componente: ¿cada pieza cumple su especificación? |
2 · El ciclo de vida en V
La V deja explícito contra qué se prueba cada cosa: las pruebas de componente se comparan contra el diseño detallado, la integración contra la arquitectura, y la validación final contra los requisitos originales — no contra lo que el equipo terminó construyendo.
Sin esa relación explícita, es fácil terminar "verificando" un sistema contra sí mismo, en vez de contra lo que realmente se pidió.
2 · El ciclo de vida en V
Une cada etapa del lado izquierdo con su pareja del lado derecho de la V.
2 · El ciclo de vida en V
Un equipo termina de construir un sistema y recién en ese momento se sienta a decidir contra qué documento va a comparar los resultados de las pruebas finales. ¿Qué principio del ciclo de vida en V no está respetando?
Sección 3
3 · Requisitos con CATWOE
Una definición raíz bien construida, con su CATWOE completo, ya es casi un requisito de ingeniería bien escrito: la T (transformación) da el requisito funcional central, y la W (Weltanschauung) da la razón de fondo que ese requisito debe cumplir.
3 · Requisitos con CATWOE
Definición raíz: "Un sistema, operado por el personal de la biblioteca, propiedad de la Dirección Académica, que transforma solicitudes de préstamo de libros en préstamos registrados con fecha de devolución controlada, en beneficio de los estudiantes y docentes, dado el catálogo físico ya existente, porque se cree que un libro prestado sin fecha de devolución clara termina perdido para el resto de la comunidad."
Requisito funcional que se deriva: "El sistema debe registrar cada préstamo con una fecha de devolución, y notificar cuando esté vencida."
3 · Requisitos con CATWOE
Capturar solo la T ("registrar préstamos") no explica por qué hace falta la fecha de devolución ni la notificación. Es la W ("un libro sin fecha de devolución clara se pierde") la que justifica ese requisito específico — y la que permite distinguir un requisito real de un capricho de implementación.
3 · Requisitos con CATWOE
Un cliente pide: "quiero que el botón de guardar sea de color verde". ¿Cómo evaluarías esta petición usando CATWOE?
3 · Requisitos con CATWOE
Clasifica cada petición según sea un requisito real (justificado por una W) o una preferencia de implementación.
¿Requisito real, o preferencia de implementación?
Sección 4
4 · Arquitectura y trade-offs
Ya viste que dos arquitecturas completamente distintas pueden cumplir igual de bien el mismo objetivo — eso es equifinalidad. Por eso la Ingeniería de Sistemas usa una técnica formal para elegir: el estudio de trade-offs (análisis de alternativas), que compara opciones contra criterios explícitos, en vez de elegir por moda o preferencia personal.
4 · Arquitectura y trade-offs
| Criterio | Monolito | Microservicios |
|---|---|---|
| Costo y tiempo de desarrollo inicial | Bajo | Alto |
| Facilidad de mantenimiento a largo plazo | Media | Alta |
| Escalabilidad ante mucho tráfico | Limitada | Alta |
Una biblioteca de una sola universidad, con tráfico bajo y un equipo pequeño, probablemente no necesita la complejidad de microservicios.
4 · Arquitectura y trade-offs
Un equipo elige arquitectura de microservicios para el sistema de la biblioteca "porque es lo que usan las grandes empresas de tecnología", sin comparar contra los criterios reales del proyecto. ¿Qué principio está ignorando?
Sección 5
5 · Verificación vs. validación
| Pregunta | Se compara contra… |
|---|---|
| Verificación: ¿estamos construyendo el sistema correctamente? | La especificación o el diseño documentado. |
| Validación: ¿estamos construyendo el sistema correcto? | La necesidad real del usuario (la W de la definición raíz). |
5 · Verificación vs. validación
Un sistema puede pasar todas las pruebas contra su especificación (verificación exitosa) y aun así no resolver el problema real de nadie, si el requisito documentado nunca capturó bien la W verdadera. Por eso ambas preguntas son necesarias, y ninguna reemplaza a la otra.
5 · Verificación vs. validación
Clasifica cada actividad según responda a verificación o a validación.
¿Verificación o validación?
Sección 6
6 · Caso práctico: Biblioteca UAB
Clasifica cada actividad del proyecto según a qué etapa del ciclo de vida en V pertenece.
1. Entrevistar a bibliotecarios y estudiantes para entender por qué se pierden libros hoy es .
2. Decidir si el sistema será web o de escritorio, y con qué base de datos, es .
3. Escribir el código que registra un préstamo en la base de datos es .
4. Un bibliotecario prueba si puede registrar un préstamo real sin errores, comparando el resultado contra el diseño detallado, es .
5. Comprobar que el módulo de préstamos y el de notificaciones funcionan juntos como se diseñó es .
6. Los estudiantes usan el sistema un mes, y la biblioteca mide si de verdad bajaron los libros perdidos, es .
6 · Caso práctico: Biblioteca UAB
Con el sistema ya en pruebas, un profesor pide agregar un botón que envíe un correo automático de recordatorio 3 días antes del vencimiento del préstamo.
Usando CATWOE (la W: "un libro sin fecha de devolución clara se pierde") y verificación vs. validación: ¿es un requisito real o una preferencia de implementación? Si se agrega, ¿contra qué se verifica y contra qué se valida?
Es un requisito real: se deriva directamente de la W del proyecto, porque un recordatorio automático reduce exactamente el riesgo que esa W describe. Se debería verificar comprobando que el correo se envía exactamente 3 días antes, tal como quedó especificado en el diseño, y validar midiendo, después de un tiempo de uso real, si efectivamente bajó la cantidad de préstamos vencidos sin devolver.
Repaso final
Repaso final
El término "systems engineering" se usó formalmente por primera vez en...
Repaso final
En el ciclo de vida en V, la validación se compara contra el diseño detallado del sistema.
Repaso final
En una definición raíz usada como requisito, ¿qué elemento de CATWOE explica por qué ese requisito importa, y no solo qué hace?
Repaso final
¿Esta actividad corresponde a verificación o a validación?
Repaso final
Un estudio de trade-offs (análisis de alternativas) sirve principalmente para...
Referencia
| Concepto | Idea clave |
|---|---|
| Ingeniería de Sistemas | Coordina hardware, software, procesos y personas como un solo sistema. |
| INCOSE | Organismo internacional (1990) que formaliza el cuerpo de conocimiento. |
| Ciclo de vida en V | El lado izquierdo define; el derecho verifica cada nivel, de abajo hacia arriba. |
| Requisito vía CATWOE | La T da el requisito funcional; la W explica por qué importa. |
| Estudio de trade-offs | Compara alternativas de arquitectura contra criterios explícitos. |
| Verificación | ¿Construimos el sistema correctamente? Contra la especificación. |
| Validación | ¿Construimos el sistema correcto? Contra la necesidad real (la W). |
Referencia
El término "systems engineering" se usó formalmente por primera vez en Bell Telephone Laboratories, en los años 40.
El INCOSE, fundado en 1990, publica el Systems Engineering Handbook, referencia en toda la industria.
El ciclo de vida en V ya se practicaba de forma intuitiva desde los años 60-70, pero se formalizó recién en 1991 (Forsberg y Mooz).
De la Teoría a la Práctica Profesional
Material de apoyo para la asignatura de Teoría General de Sistemas.
Ing. Roy Carrasco
Universidad Adventista de Bolivia · 2026