Curso de SysML (Lenguaje de Modelado para Ingeniería de Sistemas)

Comprender la evolución desde SysML v1 hasta SysML v2 y por qué ambas versiones conviven en la industria.

Identificar los diagramas clásicos de SysML v1 y su utilidad en proyectos reales.

Introducir SysML v2 como lenguaje con sintaxis textual, semántica más precisa e interoperabilidad mejorada.

Comprender el papel de KerML como base semántica de SysML v2.

Diferenciar notación gráfica, notación textual, modelo abstracto, bibliotecas y API.

Revisar herramientas habituales del ecosistema MBSE y criterios para elegir una.

Entender qué significa interoperabilidad entre herramientas de modelado, simulación, requisitos y PLM/ALM.

Valorar estrategias de transición desde SysML v1 hacia SysML v2.

Identificar riesgos de migración: pérdida de semántica, diagramas no equivalentes, librerías y dependencia de herramienta.

Crear una matriz de decisión entre mantener SysML v1, adoptar SysML v2 o trabajar en transición progresiva.

Analizar un sistema como conjunto de elementos, relaciones, funciones, comportamiento, restricciones y propósito.

Diferenciar sistema, subsistema, componente, entorno, actor, stakeholder, interfaz y frontera del sistema.

Definir el sistema de interés y evitar modelos demasiado amplios o demasiado estrechos.

Representar contexto operacional, escenarios de uso, condiciones externas y restricciones de entorno.

Aplicar descomposición sin perder visión global del sistema.

Identificar emergencias, dependencias, interacciones, acoplamientos y trade-offs.

Evitar modelos centrados solo en componentes físicos sin capturar comportamiento y requisitos.

Crear mapas iniciales de stakeholders, necesidades, funciones y límites.

Relacionar pensamiento sistémico con arquitectura funcional, lógica y física.

Realizar ejercicio de delimitación de sistema y contexto para un caso de ingeniería.

Diseñar una estructura de paquetes para requisitos, arquitectura, comportamiento, interfaces, análisis y verificación.

Crear convenciones de nombres para bloques, requisitos, actividades, estados, puertos, interfaces y relaciones.

Separar vistas de usuario, vistas técnicas, modelos de análisis y modelos de verificación.

Evitar modelos monolíticos donde todo depende de un único diagrama enorme.

Definir niveles de abstracción: conceptual, funcional, lógico, físico, implementación y verificación.

Crear bibliotecas reutilizables de elementos, tipos, unidades, interfaces y patrones.

Gestionar versiones, revisiones, estados de madurez y responsables de cada parte del modelo.

Establecer criterios de calidad: consistencia, completitud, trazabilidad, legibilidad y utilidad.

Preparar revisiones de modelo con checklist y reglas comunes.

Realizar ejercicio de creación de estructura base MBSE para un proyecto.

Identificar stakeholders internos y externos: usuarios, operadores, mantenedores, reguladores, clientes y equipos técnicos.

Capturar necesidades, objetivos, restricciones, preocupaciones y criterios de éxito.

Diferenciar necesidad, requisito, función, solución y preferencia de diseño.

Modelar casos de uso para describir interacción entre actores y sistema.

Definir actores primarios, secundarios, sistemas externos y límites de interacción.

Crear escenarios principales, escenarios alternativos y excepciones.

Relacionar casos de uso con requisitos funcionales, comportamiento y pruebas.

Evitar casos de uso demasiado técnicos que no explican valor operacional.

Preparar trazabilidad desde stakeholder need hasta requisitos y arquitectura.

Realizar ejercicio de modelado de stakeholders y casos de uso para un sistema complejo.

Crear requisitos textuales con identificador, nombre, descripción, fuente, prioridad, estado y criterio de aceptación.

Organizar requisitos en jerarquías: negocio, sistema, subsistema, funcionales, no funcionales y restricciones.

Usar relaciones de contención, derivación, refinamiento, satisfacción y verificación.

Diferenciar requisito derivado, requisito refinado, requisito satisfecho y requisito verificado.

Detectar requisitos ambiguos, no verificables, duplicados, contradictorios o mezclados con soluciones.

Relacionar requisitos con bloques, actividades, estados, interfaces y casos de prueba.

Crear matrices de trazabilidad para revisar cobertura y detectar huecos.

Gestionar cambios de requisitos y analizar impacto en arquitectura y pruebas.

Integrar requisitos SysML con herramientas externas de gestión de requisitos cuando procede.

Realizar ejercicio de modelado completo de requisitos y trazabilidad inicial.

Construir diagramas de requisitos legibles, agrupados por objetivo y nivel de abstracción.

Representar relaciones `deriveReqt`, `satisfy`, `verify`, `refine`, `trace` y dependencias relevantes.

Decidir cuándo usar diagrama y cuándo usar tabla o matriz de requisitos.

Crear vistas parciales para no saturar al lector con demasiadas relaciones.

Revisar cobertura de requisitos por arquitectura y por casos de verificación.

Detectar requisitos huérfanos, no satisfechos, no verificados o trazados a elementos incorrectos.

Preparar matrices para revisiones con cliente, ingeniería, calidad y certificación.

Gestionar estados de requisito: propuesto, aprobado, implementado, verificado, rechazado o cambiado.

Exportar documentación de requisitos desde el modelo.

Realizar ejercicio de revisión de trazabilidad con errores intencionados.

Comprender el bloque como elemento central para representar sistemas, subsistemas, componentes y elementos físicos o lógicos.

Crear Block Definition Diagrams para representar taxonomías, composición, especialización y relaciones estructurales.

Diferenciar bloque, parte, propiedad, valor, referencia, operación y constraint.

Modelar composición, agregación, asociación, generalización y dependencia.

Definir bloques lógicos y físicos sin mezclar niveles de abstracción.

Representar jerarquía de sistema, subsistemas, componentes, interfaces y elementos externos.

Crear bibliotecas de tipos reutilizables para sensores, actuadores, controladores, interfaces o materiales.

Evitar BDD convertidos en organigramas técnicos sin semántica de ingeniería.

Relacionar bloques con requisitos, actividades, estados, paramétricos y pruebas.

Realizar ejercicio de arquitectura estructural de un sistema con varios subsistemas.

Usar Internal Block Diagrams para representar la estructura interna de un bloque.

Definir partes, conectores, puertos, flujos, interfaces y relaciones entre componentes.

Diferenciar puerto estándar, puerto de flujo, proxy port, full port y representación según versión o herramienta.

Modelar interfaces eléctricas, mecánicas, software, comunicación, energía, materia o información.

Representar entradas, salidas, señales, datos, comandos, potencia, fluidos o restricciones físicas.

Crear interfaces reutilizables y evitar conectores sin semántica.

Relacionar interfaces con requisitos, comportamiento, pruebas y documentación técnica.

Detectar inconsistencias entre estructura interna y definición de bloques.

Modelar fronteras entre sistema, subsistemas, entorno y sistemas externos.

Realizar ejercicio de IBD con interfaces funcionales y físicas.

Usar diagramas de actividad para representar comportamiento, funciones, procesos y transformaciones.

Diferenciar actividad, acción, flujo de control, flujo de objeto, decisión, merge, fork y join.

Modelar cadenas funcionales desde entrada hasta salida del sistema.

Representar procesamiento de datos, energía, materia, comandos, señales o eventos.

Relacionar actividades con requisitos funcionales y bloques que las realizan.

Crear asignaciones de funciones a componentes lógicos o físicos.

Evitar diagramas de actividad convertidos en diagramas de proceso de negocio sin conexión con el sistema.

Identificar funciones críticas, redundantes, opcionales y dependientes de modo de operación.

Usar actividades como base para análisis de arquitectura funcional.

Realizar ejercicio de descomposición funcional y flujo de actividad.

Modelar estados de sistema, modos de operación, transiciones, eventos, guardas y acciones.

Diferenciar estado, subestado, transición, evento, condición, acción de entrada y acción de salida.

Representar comportamiento reactivo en sistemas embebidos, control, seguridad, operación o mantenimiento.

Modelar modos como arranque, operación normal, degradado, emergencia, fallo, mantenimiento y apagado.

Relacionar estados con requisitos, interfaces, eventos, pruebas y alarmas.

Detectar estados no alcanzables, transiciones ambiguas, condiciones incompletas y modos sin salida.

Crear tablas de estados y eventos para revisar consistencia.

Usar máquinas de estados para mejorar comunicación con software, control y validación.

Evitar mezclar comportamiento de usuario, proceso y estado técnico sin criterio.

Realizar ejercicio de máquina de estados para un sistema ciberfísico.

Usar diagramas de secuencia para representar interacción temporal entre actores, subsistemas y componentes.

Modelar mensajes síncronos, asíncronos, respuestas, activaciones, alternativas, bucles y excepciones.

Representar escenarios nominales, degradados, de fallo, mantenimiento o recuperación.

Relacionar secuencias con casos de uso, requisitos, interfaces y pruebas.

Validar si los componentes definidos en estructura pueden soportar los escenarios definidos.

Detectar mensajes sin interfaz, actores no modelados, dependencias ocultas y tiempos críticos.

Usar secuencias para alinear software, hardware, operaciones y validación.

Crear escenarios de integración entre subsistemas y sistemas externos.

Evitar secuencias demasiado detalladas que duplican diseño de código sin aportar visión de sistema.

Realizar ejercicio de escenario operativo completo con actores, componentes y excepciones.

Comprender el propósito de los diagramas paramétricos para representar restricciones entre propiedades del sistema.

Crear constraint blocks con ecuaciones, relaciones, unidades y variables.

Relacionar propiedades de bloques con restricciones de rendimiento, masa, energía, coste, fiabilidad o capacidad.

Modelar trade-offs entre requisitos y diseño mediante parámetros cuantificables.

Integrar modelos SysML con herramientas de cálculo, simulación o análisis externo.

Usar bibliotecas de unidades y magnitudes para evitar errores de interpretación.

Representar restricciones simples antes de construir modelos matemáticos complejos.

Validar consistencia entre requisitos cuantitativos y parámetros del diseño.

Evitar ecuaciones sin unidades, variables no definidas o restricciones que no se usan en análisis.

Realizar ejercicio de análisis paramétrico de rendimiento, autonomía, carga, consumo o coste.

Usar relaciones de asignación para conectar funciones con componentes, requisitos con diseño y lógica con física.

Diferenciar asignación funcional, asignación estructural, asignación de comportamiento y asignación de responsabilidad.

Crear trazabilidad entre arquitectura funcional, lógica y física.

Modelar cómo una función del sistema se implementa en subsistemas concretos.

Gestionar asignaciones many-to-many sin perder claridad ni responsabilidad.

Revisar impacto de cambios cuando una función cambia de componente o se reparte entre varios elementos.

Conectar asignaciones con decisiones de arquitectura y trade-offs.

Evitar modelos donde las funciones quedan aisladas de los componentes que las realizan.

Crear matrices de asignación para revisiones de arquitectura.

Realizar ejercicio de asignación funcional-lógica-física con análisis de impacto.

Construir arquitectura funcional basada en capacidades, funciones y flujos.

Construir arquitectura lógica como solución independiente de tecnología concreta.

Construir arquitectura física con componentes, subsistemas, interfaces y restricciones reales.

Mantener trazabilidad entre niveles sin saltar directamente de requisitos a piezas físicas.

Identificar decisiones arquitectónicas clave y documentar alternativas evaluadas.

Modelar variantes de arquitectura para comparar coste, rendimiento, fiabilidad o mantenibilidad.

Representar arquitectura de referencia, arquitectura objetivo y arquitectura implementada.

Evitar mezclar niveles de abstracción dentro del mismo diagrama.

Preparar revisiones de arquitectura con vistas adecuadas para cada stakeholder.

Realizar ejercicio de arquitectura completa de sistema desde función hasta componente.

Definir interfaces internas y externas del sistema con elementos, propiedades, flujos y responsabilidades.

Crear modelos que sirvan de base para documentos ICD o especificaciones de interfaz.

Representar datos, señales, energía, protocolos, conectores físicos, mensajes y restricciones de intercambio.

Relacionar interfaces con puertos, conectores, secuencias, requisitos y pruebas de integración.

Gestionar cambios de interfaz y analizar impacto en subsistemas afectados.

Detectar interfaces implícitas que solo aparecen en conversaciones o documentos externos.

Crear matrices de interfaz para equipos de software, hardware, mecánica, operación y soporte.

Modelar sistemas externos y condiciones de frontera.

Preparar criterios de verificación de cada interfaz crítica.

Realizar ejercicio de especificación de interfaz y análisis de impacto de cambio.

Modelar variantes de producto, configuraciones, opciones, paquetes y restricciones de compatibilidad.

Diferenciar producto base, variante, configuración, opción, feature y condición de aplicabilidad.

Representar variabilidad en requisitos, arquitectura, comportamiento, interfaces y pruebas.

Gestionar plataformas comunes y elementos específicos de cada variante.

Analizar impacto de variabilidad en documentación, fabricación, validación y mantenimiento.

Evitar duplicar modelos completos para cada variante cuando puede reutilizarse una estructura común.

Crear reglas de configuración y dependencias entre opciones.

Relacionar variabilidad con trade-offs de coste, rendimiento, seguridad o mercado.

Preparar documentación para familias de sistemas o productos configurables.

Realizar ejercicio de línea de producto con variantes y restricciones.

Diferenciar verificación, validación, análisis, inspección, demostración, prueba y simulación.

Modelar verification cases, test cases, analysis cases y evidencias asociadas.

Relacionar requisitos con casos de verificación mediante relaciones explícitas.

Diseñar matrices de cobertura requisito-prueba.

Definir criterios de aceptación claros y medibles.

Representar pruebas de integración, pruebas funcionales, pruebas de interfaz y pruebas de rendimiento.

Gestionar resultados de verificación y estado de cumplimiento.

Detectar requisitos no verificables o pruebas sin requisito asociado.

Integrar modelos SysML con herramientas de test, ALM o gestión de evidencias.

Realizar ejercicio de plan de verificación completo trazado al modelo.

Usar modelos SysML como base para análisis de rendimiento, coste, fiabilidad, seguridad, consumo o tiempos.

Identificar qué parte del modelo puede simularse y qué parte requiere herramienta externa.

Conectar restricciones paramétricas con cálculos, hojas, scripts, simuladores o modelos específicos de dominio.

Preparar escenarios de simulación vinculados a requisitos y arquitectura.

Comparar alternativas de diseño con criterios cuantitativos y cualitativos.

Documentar supuestos, valores, unidades, límites y fuentes de datos.

Evitar simulaciones sin trazabilidad hacia requisitos y decisiones de diseño.

Crear informes de análisis trade-off con justificación técnica.

Integrar resultados de análisis dentro del ciclo de decisión arquitectónica.

Realizar ejercicio de comparación de dos arquitecturas con métricas de rendimiento y coste.

Introducir la notación textual de SysML v2 y su valor para automatización, revisión, versionado y generación de modelos.

Comprender elementos básicos de sintaxis textual: packages, parts, attributes, ports, actions, requirements y relationships.

Relacionar notación textual con visualizaciones gráficas y vistas del modelo.

Entender KerML como base semántica que mejora precisión, consistencia y extensibilidad.

Revisar bibliotecas de dominio: sistemas, análisis, geometría, metadatos, unidades y derivación de requisitos.

Comprender el papel de la API estándar en integración con herramientas y ecosistema de ingeniería digital.

Comparar conceptos v1 y v2 sin asumir equivalencia directa entre todos los elementos.

Usar SysML v2 para modelos más automatizables, trazables y adecuados para pipelines digitales.

Preparar estrategia de adopción gradual en organizaciones que ya trabajan con SysML v1.

Realizar ejercicio de modelado textual básico de un sistema y generación de vistas.

Evaluar inventario de modelos SysML v1 existentes, herramientas, perfiles, bibliotecas y personalizaciones.

Identificar qué modelos deben migrarse, mantenerse, rehacerse o archivarse.

Analizar relaciones entre diagramas v1 y conceptos v2.

Preparar criterios de conversión: valor del modelo, criticidad, obsolescencia, calidad y dependencia contractual.

Definir estrategia de piloto con un subsistema limitado antes de migraciones masivas.

Revisar implicaciones de formación, herramientas, automatización, APIs y gobernanza.

Gestionar resistencia del equipo y curva de aprendizaje de notación textual.

Crear reglas de convivencia temporal entre modelos v1 y v2.

Validar que la migración mantiene requisitos, trazabilidad, interfaces y decisiones críticas.

Realizar ejercicio de transición de un fragmento de modelo v1 hacia enfoque v2.

Definir roles: model owner, systems engineer, architect, requirement engineer, verifier, domain engineer y reviewer.

Crear metodología de modelado adaptada a producto, sector, normativa y madurez de la organización.

Establecer convenciones de modelado, revisión, estados, versiones, paquetes, vistas y documentación.

Integrar SysML con procesos de requisitos, diseño, simulación, pruebas, configuración y cambio.

Definir qué información debe vivir en el modelo y qué información debe permanecer en herramientas externas.

Crear criterios de entrada y salida para revisiones de arquitectura y gates de proyecto.

Gestionar bibliotecas corporativas, patrones, perfiles, unidades, interfaces y componentes reutilizables.

Medir calidad del modelo: cobertura, trazabilidad, consistencia, defectos, reutilización y utilidad.

Evitar implantar MBSE como “otra herramienta” sin cambio de método y responsabilidades.

Realizar ejercicio de diseño de metodología MBSE para una organización.

Conectar SysML con herramientas de requisitos para mantener trazabilidad y evitar duplicidades.

Integrar modelos con ALM para software, issues, cambios, tests y evidencias.

Integrar modelos con PLM para producto, configuración, versiones, variantes y ciclo de vida.

Relacionar SysML con CAD, ECAD, simulación, análisis y documentación técnica.

Usar OSLC, APIs, exportaciones, XMI, documentos generados o conectores según herramienta.

Diseñar una arquitectura de herramientas para MBSE y digital thread.

Evitar integraciones que sincronizan datos sin owner, semántica o criterio de autoridad.

Definir fuentes maestras para requisitos, arquitectura, configuración, pruebas y documentación.

Crear entregables automáticos desde el modelo cuando el proceso lo permite.

Realizar ejercicio de mapa de integración entre SysML y ecosistema de ingeniería.

Revisar modelos con criterios de consistencia, trazabilidad, semántica, claridad, completitud y utilidad.

Detectar diagramas bonitos pero desconectados del resto del modelo.

Identificar requisitos sin verificación, bloques sin comportamiento, interfaces sin puertos y actividades sin asignación.

Corregir nombres ambiguos, duplicados, relaciones genéricas y paquetes desordenados.

Revisar si cada vista responde a una pregunta concreta de ingeniería.

Evitar exceso de detalle prematuro que bloquea avance y mantenimiento.

Crear checklist de revisión por tipo de diagrama y fase de proyecto.

Preparar sesiones de peer review del modelo con roles técnicos y de negocio.

Usar métricas de calidad para mejorar progresivamente sin burocracia excesiva.

Realizar ejercicio de auditoría de un modelo con errores intencionados.

Generar documentación técnica desde modelos SysML con vistas, tablas, matrices y explicaciones.

Preparar informes para dirección, ingeniería, calidad, cliente, certificación o proveedores.

Adaptar vistas del modelo a cada audiencia evitando sobrecarga técnica.

Crear diagramas ejecutivos, diagramas técnicos, matrices de trazabilidad y anexos detallados.

Mantener coherencia entre modelo, documentos, requisitos, pruebas y cambios.

Evitar documentación estática que queda desactualizada frente al modelo.

Crear plantillas de documentación por fase: concepto, requisitos, arquitectura, diseño, verificación y entrega.

Usar el modelo como soporte en revisiones técnicas y toma de decisiones.

Preparar narrativas claras sobre arquitectura, riesgos, interfaces y trade-offs.

Realizar ejercicio de generación de paquete documental desde un modelo SysML.

Seleccionar un sistema complejo simulado o realista con stakeholders, necesidades, requisitos, interfaces y restricciones.

Definir frontera del sistema, contexto operacional, actores, sistemas externos y escenarios de uso.

Crear estructura de paquetes, convenciones, vistas y metodología de modelado.

Modelar stakeholders, necesidades, casos de uso y escenarios principales.

Crear jerarquía de requisitos con relaciones de derivación, refinamiento, satisfacción y verificación.

Diseñar arquitectura funcional con actividades, flujos y asignaciones iniciales.

Diseñar arquitectura estructural con bloques, partes, puertos, conectores e interfaces.

Modelar comportamiento reactivo con estados, transiciones, eventos y modos de operación.

Modelar escenarios de interacción con diagramas de secuencia y excepciones relevantes.

Crear restricciones paramétricas para rendimiento, coste, masa, energía, fiabilidad u otra variable crítica.

Definir arquitectura lógica y física conectada con requisitos, funciones e interfaces.

Crear matrices de trazabilidad entre requisitos, bloques, actividades, interfaces y pruebas.

Definir casos de verificación y validación con criterios de aceptación.

Preparar un análisis trade-off entre dos alternativas de arquitectura.

Crear un fragmento equivalente o complementario en enfoque SysML v2 textual.

Diseñar plan de transición si el modelo parte de SysML v1 y se quiere evolucionar a SysML v2.

Generar documentación técnica del modelo con vistas, tablas, matrices y conclusiones.

Presentar la solución final defendiendo requisitos, arquitectura, trazabilidad, análisis, verificación y decisiones de diseño.