Ingeniería de sistemas en acción: del problema real a la solución inteligente

Esta sesión introduce a los estudiantes universitarios en el campo de la Ingeniería de Sistemas mediante el análisis y la resolución colaborativa de un problema cercano a su contexto académico. En lugar de comenzar con una definición abstracta, los estudiantes enfrentarán el caso de una universidad que necesita mejorar el sistema de reporte y seguimiento de fallas en sus aulas, laboratorios y servicios digitales. A partir de esta situación, identificarán actores, necesidades, entradas, procesos, salidas, restricciones y criterios de éxito.

El propósito es que comprendan la Ingeniería de Sistemas como una disciplina orientada a analizar problemas complejos, integrar personas, procesos, información y tecnología, y diseñar soluciones viables. Durante la sesión aplicarán conceptos introductorios de sistema, entorno, límite, componentes, interacciones y ciclo de resolución de problemas. También desarrollarán competencias de comunicación, pensamiento crítico, trabajo en equipo y argumentación técnica.

La experiencia se relaciona con situaciones reales como aplicaciones universitarias, plataformas de atención, sistemas de transporte, banca digital o servicios de salud. El enfoque de Aprendizaje Basado en Problemas permitirá que el contenido surja de las preguntas y decisiones tomadas por los estudiantes, mientras el docente actúa como facilitador y guía. Al finalizar, cada equipo presentará una propuesta inicial de sistema, justificará sus decisiones y reconocerá la importancia de comprender el problema antes de seleccionar una tecnología.

• Identificar los componentes, actores, entradas, procesos, salidas, límites y restricciones de un sistema sociotécnico.
• Analizar un problema contextualizado de Ingeniería de Sistemas, distinguiendo causas, necesidades de usuarios y criterios de éxito.
• Diseñar una representación inicial de una solución sistémica mediante un diagrama de contexto y una propuesta de funcionamiento.
• Argumentar decisiones de diseño considerando viabilidad, impacto, riesgos y necesidades de los actores involucrados.

• Computador y proyector para el docente.
• Presentación breve de 5 a 7 diapositivas sobre sistema, entorno, componentes, entradas, procesos, salidas, actores y pensamiento sistémico.
• Un video introductorio de 2 minutos sobre una falla o interrupción de un servicio digital; puede utilizarse un fragmento de una noticia tecnológica o una animación propia.
• Una ficha impresa del caso problema por equipo: “Sistema universitario de reporte y seguimiento de fallas”.
• Una plantilla impresa de análisis del problema con los apartados: actores, necesidades, entradas, procesos, salidas, restricciones, riesgos y criterios de éxito.
• Una hoja tamaño carta o pliego de papel por equipo para elaborar el diagrama de contexto.
• Marcadores de cuatro colores, notas adhesivas y cinta adhesiva; un conjunto por equipo de 3 o 4 estudiantes.
• Computadores o tabletas con acceso a Google Jamboard, Miro o Canva, como alternativa digital al trabajo en papel.
• Rúbrica breve de evaluación del análisis y la propuesta.
• Temporizador visible y tarjetas de roles: coordinador, analista de usuarios, modelador y relator.

• Comprensión básica de qué es un problema y diferencia entre causa, síntoma y solución.
• Experiencia cotidiana como usuario de aplicaciones, plataformas académicas o servicios digitales.
• Habilidad básica para organizar información en tablas, esquemas o mapas conceptuales.
• Conocimientos iniciales de informática y uso de herramientas colaborativas digitales.
• Disposición para trabajar en equipos, formular preguntas y justificar decisiones con evidencias del caso.
• Conexión curricular con contenidos previos de pensamiento lógico, análisis de procesos y comunicación técnica.

Fase de Inicio

Tiempo estimado: 20 minutos.

Propósito de la sesión

Docente: Explica: “Hoy no comenzaremos memorizando definiciones. Comenzaremos con un problema que podría ocurrir en esta universidad y construiremos una primera solución como ingenieros de sistemas. El objetivo es aprender a mirar un problema como un sistema compuesto por personas, procesos, información y tecnología”. Presenta los cuatro objetivos de aprendizaje y aclara que la evidencia principal será el análisis del caso y el diagrama de contexto.

Activación de conocimientos previos: ¿Dónde está el problema?

Tiempo: 8 minutos. Organización: individual y parejas.

• Docente: Proyecta la pregunta: “Cuando una estudiante reporta que un laboratorio no tiene conexión a Internet y el problema no se resuelve durante tres días, ¿qué elementos intervienen además de la red?”
• Estudiantes: Responden individualmente durante dos minutos y anotan al menos cinco elementos: personas, información, actividades, recursos o decisiones.
• Docente: Solicita que comparen sus respuestas en parejas y seleccionen tres elementos que consideren indispensables.
• Docente: Registra en el tablero las respuestas sin corregirlas todavía. Agrupa visualmente las ideas en personas, procesos, tecnología e información.

La pregunta permite diagnosticar si los estudiantes reducen el problema a una falla técnica o si reconocen su carácter sociotécnico. Evidencia: lista inicial de elementos y participación en la comparación.

Motivación y enganche

Tiempo: 5 minutos. Docente: Presenta un video de dos minutos sobre la interrupción de un servicio digital o muestra una captura de una plataforma con el mensaje “Error del sistema”. Luego pregunta: “¿La mejor solución sería comprar un servidor nuevo? ¿Qué información necesitaríamos antes de decidir?”. Los estudiantes votan rápidamente entre tres opciones: comprar tecnología, entrevistar usuarios o mapear el proceso. El docente no revela una respuesta única; utiliza la votación para mostrar que diseñar sistemas implica comprender antes de intervenir.

Contextualización

Tiempo: 7 minutos. Docente: Conecta el tema con situaciones que los estudiantes usan diariamente: inscripción de asignaturas, aulas virtuales, aplicaciones de transporte, pagos electrónicos y sistemas de turnos. Explica: “Cada uno de estos servicios integra usuarios, reglas, datos, infraestructura y decisiones. Si modificamos una parte sin comprender las demás, podemos crear nuevos problemas”. Presenta el caso que se trabajará en la fase siguiente y organiza equipos de 3 o 4 personas. Cada integrante selecciona un rol. Transición: “Ya identificamos elementos de un sistema desde nuestra experiencia. Ahora utilizaremos ese mismo razonamiento para analizar un caso con información, restricciones y actores concretos”.

Fase de Desarrollo

Tiempo estimado: 80 minutos.

Presentación del contenido mediante el problema

Tiempo: 12 minutos. Organización: plenaria y equipos.

Docente: Entrega y lee el siguiente caso: “Durante el último semestre, estudiantes y docentes reportaron fallas en aulas, laboratorios y plataformas digitales mediante correos, mensajes y llamadas. Los reportes se duplican, no siempre se conoce su estado y las áreas de mantenimiento no tienen información suficiente para priorizar. La universidad dispone de un presupuesto limitado y solicita una propuesta inicial de sistema que mejore el reporte, seguimiento y comunicación de las fallas”.

• El docente explica brevemente, usando el caso, los conceptos de sistema, entorno, límite, actores, entradas, procesos, salidas, retroalimentación y restricciones.
• Pregunta exactamente: “¿Qué está dentro del sistema que diseñaremos y qué pertenece al entorno?”, “¿Quién produce información?”, “¿Qué decisión debe apoyar el sistema?” y “¿Cómo sabremos que la solución funciona?”.
• Los equipos escriben dos preguntas que necesitan responder antes de proponer una solución.

Transición: “No diseñaremos todavía una aplicación. Primero investigaremos el problema con la información disponible y haremos explícitos nuestros supuestos”.

Actividad 1: Radiografía del problema

Objetivo específico: Identificar componentes, actores, entradas, procesos, salidas, límites y restricciones del sistema.

Tiempo: 30 minutos. Organización: equipos de 3 o 4.

• Docente: Entrega la plantilla de análisis y asigna una tarjeta de rol a cada integrante.
• Estudiantes: Extraen del caso los actores directos e indirectos. Deben incluir, como mínimo, estudiante, docente, personal de soporte, coordinador académico y administración.
• Estudiantes: Completan la tabla con tres entradas, tres procesos y tres salidas. Por ejemplo, un reporte, una clasificación de prioridad, una notificación o un historial de atención.
• Estudiantes: Definen el límite del sistema en una frase que empiece con: “El sistema incluirá…” y otra que empiece con: “El sistema no incluirá…”.
• Estudiantes: Registran al menos tres restricciones, como presupuesto, protección de datos, conectividad, disponibilidad del personal o integración con plataformas existentes.
• Docente: Recorre los equipos y pregunta: “¿Esta afirmación aparece en el caso o es un supuesto?”, “¿Qué actor se vería afectado si este proceso falla?” y “¿Qué salida necesita cada usuario?”.

Producto: plantilla completada y una lista separada de hechos y supuestos. El docente verifica que no confundan una solución tecnológica con el problema.

Actividad 2: Diagrama de contexto y criterios de éxito

Objetivos específicos: Analizar el problema y diseñar una representación inicial de la solución.

Tiempo: 25 minutos. Organización: equipos de 3 o 4.

• Docente: Explica que un diagrama de contexto representa el sistema como una unidad y muestra sus principales interacciones con el entorno.
• Estudiantes: Dibujan en el centro un recuadro denominado “Sistema de reporte y seguimiento de fallas”.
• Estudiantes: Ubican alrededor los actores externos y trazan flechas etiquetadas con información intercambiada: reporte, evidencia, estado, asignación, solución o notificación.
• Estudiantes: Añaden una sección titulada “criterios de éxito” y redactan cuatro indicadores observables. Ejemplos: reducir reportes duplicados, permitir consultar el estado, priorizar según impacto y notificar oportunamente.
• Estudiantes: Marcan con un color los riesgos principales y con otro las decisiones que requieren información adicional.
• Docente: Solicita que cada equipo revise si todas las flechas tienen dirección y nombre. Pregunta: “¿Qué información entra y cuál sale?”, “¿El diagrama muestra solamente tecnología o también personas y procesos?” y “¿Qué indicador demostraría una mejora real?”.

Producto: diagrama de contexto con criterios de éxito, riesgos y preguntas abiertas. Puede realizarse en papel o en Miro, Jamboard o Canva.

Actividad 3: Propuesta y defensa de una solución inicial

Objetivos específicos: Diseñar una propuesta y argumentar decisiones considerando viabilidad, impacto y riesgos.

Tiempo: 13 minutos. Organización: equipos y plenaria breve.

• Estudiantes: Redactan una propuesta de máximo cinco líneas que responda: “¿Cómo funcionaría el sistema?”, “¿Qué problema prioritario resolvería?” y “¿Qué no resolvería todavía?”.
• Estudiantes: Seleccionan una decisión de diseño y la justifican con la estructura: “Proponemos ___ porque ___; el principal beneficio sería ___; el riesgo sería ___”.
• Docente: Cada equipo presenta en 90 segundos su diagrama, propuesta y decisión principal.
• Estudiantes oyentes: Formulan una pregunta crítica iniciada por “¿Qué ocurriría si…?” o “¿Cómo comprobarían que…?”.
• Docente: Ofrece retroalimentación inmediata destacando una fortaleza y una mejora prioritaria por equipo.

Producto: exposición breve y defensa argumentada. Transición: “Sus propuestas ya muestran que una solución de sistemas debe integrar necesidades y restricciones. En el cierre verificaremos qué conceptos utilizaron y qué preguntas quedan abiertas”.

Diferenciación y apoyo

• Para quienes necesitan apoyo: se entrega una versión del caso con actores, entradas y salidas parcialmente ejemplificados; también pueden utilizar un banco de verbos: registrar, validar, clasificar, asignar, notificar y consultar. El docente realiza una mini orientación de tres minutos a los equipos que aún no delimitan el sistema.
• Para quienes terminan antes: deben agregar un escenario de excepción, por ejemplo, un reporte sin fotografía, una falla repetida o una caída de Internet, y explicar cómo respondería el sistema sin aumentar el riesgo.
• Para diferentes formas de aprendizaje: se permite representar la solución mediante diagrama, tabla o flujo visual, siempre que se evidencien actores, interacciones, criterios y restricciones.

Fase de Cierre

Tiempo estimado: 20 minutos.

Síntesis colectiva

Tiempo: 8 minutos. Organización: plenaria.

Docente: Dibuja en el tablero una matriz con cuatro columnas: “Problema”, “Sistema”, “Decisión” y “Evidencia”. Solicita a cada equipo que aporte una idea en una columna distinta. Después pregunta: “¿Qué diferencia hay entre describir una falla y analizar el sistema que la produce?”. Con las respuestas, construye una síntesis de tres ideas: un sistema integra elementos relacionados; el límite determina qué se analiza; y una solución debe justificarse con necesidades, restricciones y criterios de éxito.

Estudiantes: Comparan la síntesis con su producto y realizan una corrección visible en el diagrama o en la plantilla. Esta modificación constituye evidencia de aprendizaje y evita que el cierre sea únicamente expositivo.

Reflexión metacognitiva y ticket de salida

Tiempo: 7 minutos. Organización: individual.

El docente entrega un ticket de salida con las siguientes preguntas exactas:

• “¿Qué componente del sistema identifiqué con mayor claridad y qué evidencia del caso respalda mi identificación?”
• “¿Qué supuesto realizó mi equipo y qué pregunta deberíamos investigar para validarlo?”
• “¿Qué decisión de diseño cambiaría si el presupuesto se redujera a la mitad? Justifica tu respuesta considerando al menos un actor y un criterio de éxito”.

Los estudiantes responden en cinco minutos y entregan el ticket. Estas preguntas verifican la identificación, el análisis, el diseño y la argumentación desarrollados durante la sesión.

Retroalimentación, transferencia y reto

Tiempo: 5 minutos. Docente: Proyecta tres errores frecuentes observados: confundir el problema con la solución, omitir actores y proponer funciones sin criterios de éxito. Explica cómo corregirlos y relaciona cada error con un ejemplo de los trabajos. Luego indica: “En la siguiente clase utilizaremos las preguntas abiertas de sus diagramas para convertir necesidades en requisitos verificables”.

Tarea o reto: Cada estudiante deberá observar un sistema cotidiano, como una aplicación de transporte, una plataforma de pagos o el aula virtual, y entregar una página con: propósito del sistema, tres actores, dos entradas, dos salidas, un límite, una restricción y una oportunidad de mejora. Deberá incluir una breve justificación basada en su experiencia como usuario.

Tipo y momentos de evaluación

• Diagnóstica: se aplica durante la activación de conocimientos previos, en los minutos 2 a 8 del inicio, mediante la identificación de elementos que intervienen en una falla de servicio.
• Formativa: se aplica durante las actividades 1 y 2 del desarrollo, mediante observación directa, preguntas guía, revisión de la plantilla y análisis del diagrama.
• Sumativa: se aplica durante la presentación de la propuesta, el ticket de salida y la revisión del producto final del equipo en el cierre.

Criterios de evaluación vinculados con los objetivos

• Identificación sistémica: reconoce actores, entradas, procesos, salidas, límites y restricciones relevantes. Vinculado con el objetivo 1.
• Análisis del problema: diferencia hechos, supuestos, causas, necesidades de usuarios y criterios de éxito. Vinculado con el objetivo 2.
• Representación de la solución: construye un diagrama de contexto claro, coherente y con interacciones correctamente etiquetadas. Vinculado con el objetivo 3.
• Argumentación técnica: justifica una decisión de diseño considerando viabilidad, impacto, riesgos y actores afectados. Vinculado con el objetivo 4.

Instrumentos sugeridos

• Rúbrica analítica de cuatro niveles para valorar la plantilla, el diagrama y la presentación: inicial, básico, competente y destacado.
• Lista de cotejo para verificar presencia de actores, entradas, procesos, salidas, límites, restricciones, criterios de éxito y riesgos.
• Observación directa del trabajo colaborativo, la formulación de preguntas y el uso de evidencias del caso.
• Autoevaluación individual mediante el ticket de salida.
• Coevaluación breve después de las presentaciones, usando una pregunta crítica y una fortaleza identificada por equipo.

Evidencias de aprendizaje

• Lista inicial de elementos que intervienen en una falla de servicio.
• Plantilla de radiografía del problema con hechos, supuestos, actores y restricciones.
• Diagrama de contexto del sistema universitario de reporte y seguimiento de fallas.
• Propuesta escrita de solución y defensa oral de una decisión de diseño.
• Ticket de salida con reflexión sobre componentes, supuestos y decisiones.
• Reto individual de transferencia aplicado a un sistema cotidiano.