Representando sistemas con modelos

Un modelo es una representación simplificada de un sistema en algún momento

particular en el tiempo o espacio destinado a promover la comprensión del sistema real.
Como una abstracción de un sistema, ofrece información sobre uno o más de los
aspectos del sistema, como su función, estructura, propiedades, rendimiento,
comportamiento o costo.

Visión general
El modelado de sistemas como entidades holísticas que proporcionan valor ha ido
ganando reconocimiento como un proceso central de ingeniería de sistemas. El uso del
modelado y la simulación durante las primeras etapas del diseño del sistema de
sistemas y arquitecturas complejas puede:

• Documentar las funciones y requisitos del sistema.

• evaluar el desempeño de la misión,
• estimar costos,
• evaluar las compensaciones, y
• Proporcionar información para mejorar el rendimiento, reducir el riesgo y
administrar los costos.
El modelado y el análisis pueden complementar las pruebas y la evaluación que se
producen más adelante en el ciclo de vida. En algunos sistemas, el modelado y la
simulación pueden ser la única forma de evaluar completamente el rendimiento (por
ejemplo, la defensa con misiles balísticos) o de evaluar el rendimiento del sistema en
escenarios severos (por ejemplo, la respuesta a los ataques de armas de destrucción
masiva en la patria). Además, simulaciones avanzadas, por ej. Los simuladores de vuelo
y las simulaciones de los centros de mando y control pueden ser una técnica rentable
para la capacitación del personal en acompañamiento con la capacitación del sistema
operativo (INCOSE 2012).
El modelado sirve para hacer conceptos concretos y formales, mejorar la calidad, la
productividad, la documentación y la innovación, así como para reducir el costo y el
riesgo del desarrollo de sistemas.
El modelado ocurre en muchos niveles: componente, subsistema, sistema y sistemas
de sistemas; y a lo largo del ciclo de vida de un sistema. Es posible que se necesiten
diferentes tipos de modelos para representar sistemas en apoyo del análisis,
especificación, diseño y verificación de sistemas. Esta área de conocimiento
proporciona una visión general de los modelos utilizados para representar diferentes
aspectos de los sistemas.
El modelado es una práctica común que es compartida por la mayoría de las disciplinas
de ingeniería, incluyendo:
• Ingeniería eléctrica, que utiliza modelos de diseño de circuitos eléctricos.
• Ingeniería mecánica, que utiliza modelos tridimensionales de diseño asistido por
ordenador.
• Ingeniería de software, que utiliza modelos de arquitectura y diseño de software.
Cada una de estas disciplinas tiene su propio lenguaje con su sintaxis y semántica, que
sirve como un medio de comunicación entre los profesionales en esa disciplina. Los
modelos analíticos se utilizan para admitir análisis de energía, térmicos, estructurales y
en tiempo real integrados.
Los estándares de modelado desempeñan un papel importante en la definición de
conceptos de modelado de sistemas que se pueden representar para un dominio
particular de interés y permiten la integración de diferentes tipos de modelos en dominios
de interés.

Temas
Cada parte de la Guía del Cuerpo de Conocimientos de Ingeniería de Sistemas (SEBoK)
se divide en áreas de conocimiento (KA), que son agrupaciones de información con un
tema relacionado. Las áreas de conocimiento a su vez se dividen en temas. Esta área
de conocimiento contiene los siguientes temas:
• ¿Qué es un modelo?
• ¿Por qué modelar?
• Tipos de modelos
• Conceptos de modelado de sistemas
• Normas de modelado
• Integración de los aspectos de apoyo en los modelos del sistema

Referencias
Trabajos citados
INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and
Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering
(INCOSE), INCOSE-TP-2003-002-03.2.2.

Referencias primarias
Dori, D. 2002. Object-Process Methodology – A Holistic Systems Paradigm. Berlin, Germany:
Springer Verlag.

Estefan, J. 2008. A Survey of Model-Based Systems Engineering (MBSE) Methodologies, rev, B.

Seattle, WA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Accedido
el 13 de abril de 2015 en http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf

Friedenthal, S., A. Moore, R. Steiner, and M. Kaufman. 2012. A Practical Guide to SysML: The
Systems Modeling Language, 2nd Edition. Needham, MA, USA: OMG Press.

Guizzardi, G. 2007. On Ontology, Ontologies, Conceptualizations, Modeling Languages, and

(Meta) Models.

Proceedings of the Databases and Information Systems IV Conference, Amsterdam,

Netherlands. Accedido el 4 de diciembre de 2014 en ACM
http://portal.acm.org/citation.cfm?id=1565425.

INCOSE. 2007. Systems Engineering Vision 2020. Seattle, WA, USA: International Council on
Systems Engineering. September 2007. INCOSE-TP-2004-004-02.

Wymore, A.W. 1993. Model-Based Systems Engineering. Boca Raton, FL, USA: CRC Press, Inc.

Referencias Adicionales
Holt, J. and S. Perry. 2008. SysML for systems engineering. Stevenage: Institution of Engineering
and Technology. Accedido el 4 de diciembre de 2014 en Ebrary
http://site.ebrary.com/id/10263845.

Grobshtein, Y. and D. Dori. 2011. "Generating SysML Views from an OPM Model: Design and
Evaluation." Systems Engineering. 14(3), Sept.

West, P., J. Kobza, and S. Goerger. 2011. "Chapter 4, Systems Modeling and Analysis," in
Parnell, G.S., P.J. Driscoll, and D.L Henderson (eds). Decision Making for Systems Engineering
and Management, 2da ed. Wiley Series in Systems Engineering. Hoboken, NJ: Wiley & Sons Inc.

Discusión de SEBoK
Por favor, proporcione sus comentarios y comentarios sobre el SEBoK a continuación. Deberá
iniciar sesión en DISQUS utilizando una cuenta existente (por ejemplo, Yahoo, Google,
Facebook, Twitter, etc.) o crear una cuenta DISQUS. Simplemente escriba su comentario en el
campo de texto a continuación y DISQUS lo guiará a través de los pasos de inicio de sesión o
registro. Los comentarios se archivarán y se utilizarán para futuras actualizaciones de SEBoK.
Si proporcionó un comentario que ya no está en la lista, ese comentario ha sido adjudicado.
Puede ver la adjudicación de los comentarios enviados antes de SEBoK v. 1.0 en la Revisión y
Adjudicación de SEBoK. Los comentarios posteriores se tratan y los cambios se resumen en la
Carta del Editor y en Reconocimientos e Historial de lanzamientos.

Si desea realizar ediciones en este artículo, recomendar nuevo contenido o hacer comentarios
sobre el SEBoK en su conjunto, consulte el Sandbox de SEBoK [1].
¿Qué es un modelo?
Este tema proporciona conceptos fundamentales, como las definiciones de un modelo
y un lenguaje de modelado, y expresa sus relaciones con las herramientas de modelado
y la ingeniería de sistemas basada en modelos (MBSE).

Definición de un modelo
Hay muchas definiciones de la palabra modelo. Las siguientes definiciones se refieren
a un modelo como una representación de aspectos seleccionados de un dominio de
interés para el modelador:
• una representación física, matemática o lógica de un sistema, entidad, fenómeno
o proceso (DoD 1998);
• una representación de uno o más conceptos que pueden realizarse en el mundo
físico (Friedenthal, Moore y Steiner 2009);
• una representación simplificada de un sistema en algún momento particular en
el tiempo o espacio destinado a promover la comprensión del sistema real
(Bellinger 2004);
• una abstracción de un sistema, dirigida a comprender, comunicar, explicar o
diseñar aspectos de interés de ese sistema (Dori 2002); y
• una representación selectiva de algún sistema cuya forma y contenido se eligen
en función de un conjunto específico de inquietudes; El modelo está relacionado
con el sistema mediante una asignación explícita o implícita (Object
Management Group 2010).
En el contexto de la ingeniería de sistemas, un modelo que representa un sistema y su
entorno es de particular importancia para el ingeniero de sistemas, que debe especificar,
diseñar, analizar y verificar los sistemas, así como compartir información con otras
partes interesadas. Se utilizan diversos modelos de sistemas para representar
diferentes tipos de sistemas para diferentes propósitos de modelado. Algunos de los
propósitos de los sistemas de modelado se resumen en el tema ¿Por qué modelar?, y
una taxonomía simple de los diferentes tipos de modelos se describe en el tema Tipos
de modelos. El tema de estándares de modelado se refiere a algunos de los lenguajes
de modelado de sistemas estándar y otros estándares de modelado que admiten MBSE.
Un modelo puede tener diferentes formas como se indica en la primera definición
anterior, incluyendo una representación física, matemática o lógica. Un modelo físico
puede ser una maqueta que representa un sistema real, como un avión modelo. Un
modelo matemático puede representar posibles trayectorias de vuelo en términos de
aceleración, velocidad, posición y orientación. Un modelo lógico puede representar
relaciones lógicas que describen las posibles causas de falla del avión, como por
ejemplo, cómo una falla del motor puede ocasionar una pérdida de potencia y hacer que
el avión pierda altura, o cómo las partes del sistema están interconectadas. Es evidente
que se pueden requerir muchos modelos diferentes para representar un sistema de
interés (SoI).
Lenguaje de modelado
Un modelo físico es una representación concreta de un sistema real que se puede sentir
y tocar. Otros modelos pueden ser representaciones más abstractas de un sistema o
entidad. Estos modelos se basan en un lenguaje de modelado para expresar su
significado como se explica en "Ontología, ontologías, conceptualizaciones, lenguajes
de modelado y modelos (meta)" (Guizzardi 2007).
Así como los dibujos de ingeniería expresan la estructura 3D de los diseños mecánicos
y arquitectónicos, los modelos conceptuales son los medios por los cuales los sistemas
se conciben, se arquitecturan, se diseñan y se construyen. Los modelos resultantes son
las contrapartes del proyecto de diseño mecánico. Sin embargo, la diferencia es que si
bien los planos son representaciones exactas de artefactos físicos con una sintaxis
precisa y acordada y una larga tradición de servir como un medio de comunicación entre
profesionales, los modelos conceptuales apenas están comenzando a avanzar hacia
una completa e inequívoca representación de un sistema en desarrollo. Los artículos en
la sección especial de Comunicaciones de la Association for Computing Machinery
(ACM) (Dori 2003) presentan el mundo abstracto del análisis y la arquitectura de
sistemas mediante modelos conceptuales y cómo evaluar, seleccionar y construir
modelos.
Los lenguajes de modelado generalmente están destinados a ser interpretables por el
hombre y por computadora, y se especifican en términos de sintaxis y semántica.
La sintaxis abstracta especifica las construcciones del modelo y las reglas para construir
el modelo. En el caso de un lenguaje natural como el inglés, las construcciones pueden
incluir tipos de palabras como verbos, sustantivos, adjetivos y preposiciones, y las reglas
especifican cómo estas palabras pueden usarse juntas para formar oraciones
adecuadas. La sintaxis abstracta para un modelo matemático puede especificar
construcciones para definir funciones matemáticas, variables y su relación. La sintaxis
abstracta para un modelo lógico también puede especificar construcciones para definir
entidades lógicas y sus relaciones. Un modelo bien formado obedece a las reglas de
construcción, así como una oración bien formada debe ajustarse a las reglas
gramaticales del lenguaje natural.
La sintaxis concreta especifica los símbolos utilizados para expresar las construcciones
del modelo. El idioma natural inglés se puede expresar en texto o código morse. Un
lenguaje de modelado se puede expresar utilizando símbolos gráficos y / o
declaraciones de texto. Por ejemplo, un modelo de flujo funcional se puede expresar
utilizando símbolos gráficos que consisten en una combinación de nodos gráficos y
arcos anotados con texto; mientras que un lenguaje de modelado de simulación puede
expresarse usando una sintaxis de texto de lenguaje de programación como el lenguaje
de programación C.
La semántica de un lenguaje define el significado de las construcciones. Por ejemplo,
una palabra en inglés no tiene un significado explícito hasta que la palabra está definida.
De manera similar, una construcción que se expresa como un símbolo, como un cuadro
o una flecha en un diagrama de flujo, no tiene significado hasta que se define. El
lenguaje debe dar significado al concepto de un verbo o sustantivo, y debe dar un
significado específico a una palabra específica que es un verbo o sustantivo. La
definición puede establecerse proporcionando una definición de lenguaje natural, o
asignando el constructo a un formalismo cuyo significado está definido. Como ejemplo,
un símbolo gráfico que expresa sin(x) y cos(x) se define utilizando un formalismo
matemático bien definido para la función seno y coseno. Si la posición de un péndulo se
define en términos de sin(θ) y cos(θ), el significado de la posición del péndulo se
entiende en términos de estos formalismos.

Herramientas de modelado
Los modelos son creados por un modelador usando herramientas de modelado. Para
los modelos físicos, las herramientas de modelado pueden incluir taladros, tornos y
martillos. Para modelos más abstractos, las herramientas de modelado suelen ser
programas de software que se ejecutan en una computadora. Estos programas
proporcionan la capacidad de expresar construcciones de modelado utilizando un
lenguaje de modelado particular. Un procesador de textos se puede ver como una
herramienta que se usa para construir descripciones de texto en lenguaje natural. De
manera similar, las herramientas de modelado se utilizan para construir modelos
utilizando lenguajes de modelado. La herramienta a menudo proporciona una paleta de
herramientas para seleccionar símbolos y un área de contenido para construir el modelo
a partir de los símbolos gráficos u otra sintaxis concreta. Una herramienta de modelado
generalmente verifica el modelo para evaluar si cumple con las reglas del lenguaje, y
aplica tales reglas para ayudar al modelador a crear un modelo bien formado. Esto es
similar a la forma en que un procesador de textos verifica el texto para ver que cumple
con las reglas gramaticales del lenguaje natural.
Algunas herramientas de modelado son productos disponibles comercialmente,
mientras que otras pueden crearse o personalizarse para proporcionar soluciones de
modelado únicas. Las herramientas de modelado a menudo se usan como parte de un
conjunto más amplio de herramientas de ingeniería que constituyen el entorno de
desarrollo de sistemas. Existe un mayor énfasis en el soporte de herramientas para
lenguajes de modelado estándar que permiten intercambiar modelos e información de
modelado entre diferentes herramientas.

Relación del modelo con la ingeniería de sistemas basada en modelos

El Consejo Internacional de Ingeniería de Sistemas (INCOSE) INCOSE Systems
Engineering Vision 2020 (2007) define MBSE como “la aplicación formalizada de
modelado para respaldar los requisitos del sistema, el diseño, el análisis, la verificación
y las actividades de validación que comienzan en la fase de diseño conceptual y
continúan durante todo el desarrollo y fases posteriores del ciclo de vida”. En MBSE, los
modelos del sistema son artefactos principales del proceso de ingeniería de sistemas, y
se administran, controlan e integran con otras partes de la línea de base técnica del
sistema. Esto contrasta con el enfoque tradicional centrado en el documento para la
ingeniería de sistemas, donde la documentación y las especificaciones basadas en texto
se administran y controlan. El uso de un enfoque basado en modelos para la ingeniería
de sistemas tiene como objetivo dar como resultado mejoras significativas en la
especificación del sistema y la calidad del diseño, menor riesgo y costo del desarrollo
del sistema al surgir problemas al inicio del proceso de diseño, productividad mejorada
mediante la reutilización de los artefactos del sistema y comunicaciones mejoradas entre
los equipos de desarrollo e implementación del sistema.
Además de crear modelos, el enfoque de MBSE generalmente incluye métodos para la
gestión de modelos con el objetivo de garantizar que los modelos se controlan
adecuadamente y métodos para la validación de modelos con el objetivo de garantizar
que los modelos representan con precisión los sistemas que se están modelando.
La wiki MBSE INCOSE / Object Management Group (OMG) patrocinada conjuntamente
proporciona información adicional sobre la Iniciativa MBSE INCOSE, incluidas algunas
aplicaciones de MBSE y algunos temas clave relacionados con MBSE, como las
secciones Metodología y métricas y Gestión de modelos.
El Informe Final del Subcomité de Ingeniería Basada en Modelos (MBE), que fue
generado por el Comité de Modelado y Simulación de la Asociación Nacional de
Industrias de Defensa (NDIA) de la División de Ingeniería de Sistemas, destaca muchos
de los beneficios, riesgos y desafíos de un modelo basado en enfoque, e incluye muchas
referencias a estudios de caso de MBE (NDIA 2011).

Breve historia de lenguajes y métodos de modelado de sistemas

Muchos métodos de modelado de sistemas y lenguajes de modelado asociados se han
desarrollado e implementado para admitir diversos aspectos del análisis, diseño e
implementación del sistema. Los lenguajes de modelado funcional incluyen el diagrama
de flujo de datos (DFD) (Yourdon y Constantine 1979), la Definición de integración para
el modelado funcional (IDEF0) (Menzel y Maier 1998) y el diagrama de bloque de flujo
funcional mejorado (eFFBD). Otras técnicas de modelado de comportamiento incluyen
el diagrama de transición de estado clásico, los gráficos de estado (Harel 1987) y los
diagramas de flujo del proceso. Las técnicas de modelado estructural incluyen
diagramas de estructura de datos (Jackson 1975), diagramas de relaciones de entidad
(Chen 1976) y técnicas de modelado de objetos (Rumbaugh et al. 1991), que combinan
diagramas de objetos, DFD y gráficos de estado.
Algunos de los métodos y lenguajes de modelado de sistemas recientes evolucionaron
a partir de estas raíces y se destacan en una encuesta sobre metodologías de ingeniería
de sistemas basados en modelos (MBSE) (Estefan 2008). Esta encuesta identifica
varias metodologías de MBSE candidatas y lenguajes de modelado que pueden
aplicarse para respaldar un enfoque MBSE. Métodos de modelado adicionales están
disponibles en el MBSE Wiki en la sección Metodología y Métricas. La sección de
estándares de modelado se refiere a algunos de los lenguajes de modelado de sistemas
estándar y otros estándares de modelado que admiten MBSE.

Referencias
Trabajos citados
Bellinger, G. 2004. "Modeling & Simulation: An Introduction," en Mental Model Musings.
Disponible en: http:/ / www.systems-thinking.org/modsim/modsim.htm.

Chen, P. 1976. "The Entity Relationship Model – Toward a Unifying View of Data." ACM
Transactions on Data Base Systems 1(1): 9-36.

DoD. 1998. "'DoD Modeling and Simulation (M&S) Glossary" in DoD Manual 5000.59-M.
Arlington, VA, USA: US Department of Defense. January. P2.13.22. Disponible en:
http://www.dtic.mil/whs/directives/ corres/ pdf/500059m.pdf
Dori, D. 2002. Object-Process Methodology: A Holistic System Paradigm. New York, NY, USA:
Springer.

Dori, D. 2003. "Conceptual Modeling and System Architecting." Communications of the ACM,
46(10), pp. 62-65.[3]

Estefan, J. 2008. “A Survey of Model-Based Systems Engineering (MBSE) Methodologies,” rev.

B, Seattle, WA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-02.

Friedenthal, S., A. Moore, R. Steiner, and M. Kaufman. 2012. A Practical Guide to SysML: The
Systems Modeling Language, 2da Edición. Needham, MA, USA: OMG Press.

Guizzardi, G. 2007. "On Ontology, Ontologies, Conceptualizations, Modeling Languages, and

(Meta) Models" Proceedings of Seventh International Baltic Conference. Amsterdam, the
Netherlands. Disponible en http://portal.acm.org/citation.cfm?id=1565425.

Harel, D. 1987. "Statecharts: A Visual Formalism for Complex Systems." Science of Computer
Programming. 8(3): 231–74.

Jackson, M.A. 1975. Principles of Program Design. New York, NY, USA: Academic Press.

Menzel, C. and R.J. Mayer. 1998. "The IDEF Family of Languages." in P. Bernus, K. Mertins, and
G. Schmidt (eds.). Handbook on Architectures for Information Systems. Berlin, Germany:
Springer-Verlag. p. 209-241.

OMG. 2010. MDA Foundation Model. Needham, MA, USA: Object Management Group.
ORMSC/2010-09-06.

Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, and W. Lorenson. 1990. Object-Oriented

Modeling and Design.

Upper Saddle River, NJ: Prentice Hall.

Press, Y. and L.L. Constantine. 1976. Structured Design: Fundamentals of a Discipline of

Computer Program and Systems Design. Upper Saddle River, NJ: Prentice Hall.

Yourdon E. and Constantine L.L. 1973. Structured Design: Fundamentals of a Discipline of

Computer Program and Systems Design. Prentice-Hall, Inc. Upper Saddle River, NJ, USA. 1st
Edition.

Referencias primarias
Estefan, J. 2008. A Survey of Model-Based Systems Engineering (MBSE) Methodologies, Rev.
B. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-
02. Disponible en:
http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-
0610_RevB-JAE2.pdf.

Guizzardi, G. 2007. "On Ontology, Ontologies, Conceptualizations, Modeling Languages, and

(Meta)Models." Proceedings of Seventh International Baltic Conference. Amsterdam, The
Netherlands. Disponible en http://portal.acm.org/citation.cfm?id=1565425.

INCOSE. 2007. Systems Engineering Vision 2020. Seattle, WA, USA: International Council on
Systems Engineering. September 2007. INCOSE-TP-2004-004-02.

NDIA. 2011. Final Report of the Model Based Engineering (MBE) Subcommittee. Arlington, VA,
USA: National Defense Industrial Association. Disponible en:
http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/M_S%20
Committee/Reports/MBE_Final_Report_Document_(2011-04-22)_Marked_Final_Draft.pdf
Referencias adicionales
Downs, E., P. Clare, and I. Coe. 1992. Structured Systems Analysis and Design Method:
Application and Context. Hertfordshire, UK: Prentice-Hall International.

Eisner, H. 1988. Computer-Aided Systems Engineering. Englewood Cliffs, NJ, USA: Prentice
Hall.

Harel, D. 1987. "Statecharts: A Visual Formalism for Complex Systems." Science of Computer
Programming. 8(3): 231–74.

Kossiakoff, A. and W. Sweet. 2003. "Chapter 14" in Systems Engineering Principles and Practice.
New York, NY, USA: Wiley and Sons.

OMG. "MBSE Wiki." Object Management Group (OMG). Accessed 11 September 2011.
Disponible en: http://www.omgwiki.org/MBSE/doku.php.

Oliver, D., T. Kelliber, and J. Keegan. 1997. Engineering Complex Systems with Models and
Objects. New York, NY, USA: McGraw-Hill.

Discusión de SEBoK
Por favor, proporcione sus comentarios y comentarios sobre el SEBoK a continuación. Deberá
iniciar sesión en DISQUS utilizando una cuenta existente (por ejemplo, Yahoo, Google,
Facebook, Twitter, etc.) o crear una cuenta DISQUS. Simplemente escriba su comentario en el
campo de texto a continuación y DISQUS lo guiará a través de los pasos de inicio de sesión o
registro. Los comentarios se archivarán y se utilizarán para futuras actualizaciones de SEBoK.
Si proporcionó un comentario que ya no está en la lista, ese comentario ha sido adjudicado.
Puede ver la adjudicación de los comentarios enviados antes de SEBoK v. 1.0 en la Revisión y
Adjudicación de SEBoK. Los comentarios posteriores se tratan y los cambios se resumen en la
Carta del Editor y en Reconocimientos e Historial de lanzamientos.

Si desea realizar ediciones en este artículo, recomendar nuevo contenido o hacer

comentarios sobre el SEBoK en su conjunto, consulte el Sandbox de SEBoK [1].
¿Por qué modelar?
Los modelos del sistema se pueden utilizar para muchos propósitos. Este tema destaca
algunos de esos propósitos y proporciona indicadores de un modelo efectivo, en el
contexto de la ingeniería de sistemas basada en modelos (MBSE).

Propósito de un modelo
Los modelos son representaciones que pueden ayudar a definir, analizar y comunicar
un conjunto de conceptos. Los modelos de sistemas se desarrollan específicamente
para respaldar el análisis, especificación, diseño, verificación y validación de un sistema,
así como para comunicar cierta información. Uno de los primeros principios del
modelado es definir claramente el propósito del modelo. Algunos de los propósitos que
los modelos pueden cumplir a lo largo del ciclo de vida del sistema son:
 Caracterización de un sistema existente: muchos sistemas existentes están
mal documentados, y modelar el sistema puede proporcionar una forma concisa
de capturar el diseño del sistema existente. Esta información se puede utilizar
para facilitar el mantenimiento del sistema o para evaluar el sistema con el
objetivo de mejorarlo. Esto es análogo a la creación de un modelo arquitectónico
de un edificio antiguo con recubrimientos para electricidad, plomería y estructura
antes de proceder a su actualización a nuevos estándares para resistir
terremotos.
 Formulación y evaluación del concepto de misión y sistema: Los modelos
pueden aplicarse temprano en el ciclo de vida del sistema para sintetizar y
evaluar conceptos de misión y sistema alternativos. Esto incluye definir de
manera clara e inequívoca la misión del sistema y el valor que se espera que
entregue a sus beneficiarios. Los modelos se pueden usar para explorar un
espacio comercial al modelar diseños de sistemas alternativos y evaluar el
impacto de los parámetros críticos del sistema, como el peso, la velocidad, la
precisión, la confiabilidad y el costo en las medidas globales de mérito. Además
de limitar los parámetros de diseño del sistema, los modelos también se pueden
usar para validar que los requisitos del sistema satisfacen las necesidades de
los interesados antes de continuar con las actividades posteriores del ciclo de
vida, como sintetizar el diseño detallado del sistema.
 Síntesis de diseño del sistema y flujo de requisitos: los modelos se pueden
usar para apoyar soluciones de arquitectura de sistema, así como la misión de
flujo y los requisitos del sistema hasta los componentes del sistema. Pueden
requerirse diferentes modelos para abordar diferentes aspectos del diseño del
sistema y responder a la amplia gama de requisitos del sistema. Esto puede
incluir modelos que especifican requisitos funcionales, de interfaz, de
rendimiento y físicos, así como otros requisitos no funcionales, como
confiabilidad, mantenimiento y seguridad.
 Soporte para la integración y verificación del sistema: los modelos se
pueden usar para admitir la integración de los componentes de hardware y
software en un sistema, así como para verificar que el sistema cumple con sus
requisitos. A menudo, esto implica la integración de modelos de diseño de
hardware y software de nivel inferior con modelos de diseño a nivel de sistema
que verifican que se cumplan los requisitos del sistema. La integración y
verificación del sistema también puede incluir el reemplazo de los modelos
 seleccionados de hardware y diseño con productos de software y hardware
reales para verificar de manera incremental que se cumplen los requisitos del
sistema. Esto se conoce como pruebas de hardware en el bucle y pruebas de
software en el bucle. Los modelos también se pueden usar para definir los casos
de prueba (glosario) y otros aspectos del programa de prueba para ayudar en la
planificación y ejecución de la prueba.
 Soporte para la capacitación: los modelos se pueden utilizar para simular
diversos aspectos del sistema para ayudar a capacitar a los usuarios a
interactuar con el sistema. Los usuarios pueden ser operadores, mantenedores
u otras partes interesadas. Los modelos pueden ser la base para desarrollar un
simulador (glosario) del sistema con diversos grados de fidelidad para
representar la interacción del usuario en diferentes escenarios de uso.
 Captura de conocimiento y evolución del diseño del sistema: los modelos
pueden proporcionar un medio eficaz para capturar el conocimiento sobre el
sistema y retenerlo como parte del conocimiento de la organización. Este
conocimiento, que se puede reutilizar y evolucionar, proporciona una base para
respaldar la evolución del sistema, como el cambio de los requisitos del sistema
ante tecnologías emergentes, relevantes, nuevas aplicaciones y nuevos clientes.
Los modelos también pueden permitir la captura de familias de productos.

Indicadores de un modelo efectivo

Cuando el modelado se hace bien, los propósitos de un modelo son claros y bien
definidos. El valor de un modelo puede evaluarse en términos de la eficacia con la que
apoya esos propósitos. El resto de esta sección y los temas Tipos de modelos,
conceptos de modelado de sistemas y estándares de modelado describen indicadores
de un modelo efectivo (Friedenthal, Moore y Steiner 2012).

Alcance del modelo

El modelo debe tener un alcance para abordar su propósito previsto. En particular, los
tipos de modelos y los lenguajes de modelado asociados seleccionados deben ser
compatibles con las necesidades específicas que deben cumplirse. Por ejemplo,
supongamos que los modelos están construidos para soportar el desarrollo de un avión.
Un modelo de arquitectura del sistema puede describir la interconexión entre las partes
del avión, un modelo de análisis de trayectoria puede analizar la trayectoria del avión y
un modelo de análisis de árbol de fallas puede evaluar las posibles causas de falla del
avión.
Para cada tipo de modelo, la amplitud, profundidad y fidelidad adecuadas deben
determinarse para abordar el propósito previsto del modelo. La amplitud del modelo
refleja la cobertura de los requisitos del sistema en términos del grado en que el modelo
debe abordar los requisitos funcionales, de interfaz, de rendimiento y físicos, así como
otros requisitos no funcionales, como la confiabilidad, la capacidad de mantenimiento y
la seguridad. Para un modelo funcional de avión, la amplitud del modelo puede ser
necesaria para abordar algunos o todos los requisitos funcionales para encender,
despegar, volar, aterrizar, apagar y mantener el entorno del avión.
La profundidad del modelo indica la cobertura de la descomposición del sistema desde
el contexto del sistema hasta los componentes del sistema. Para el ejemplo del avión,
el alcance de un modelo puede requerir que defina el contexto del sistema, desde la
aeronave, la torre de control y el entorno físico, hasta el subsistema de navegación y
sus componentes, como la unidad de medición inercial; y, tal vez, a partes inferiores de
la unidad de medición inercial.
La fidelidad del modelo indica el nivel de detalle que el modelo debe representar para
cualquier parte del modelo. Por ejemplo, un modelo que especifica las interfaces del
sistema puede ser bastante abstracto y representar solo el contenido de información
lógica, como los datos de estado de la aeronave; o, puede ser mucho más detallado
para admitir información de mayor fidelidad, como la codificación de un mensaje en
términos de bits, bytes y características de la señal. La fidelidad también puede referirse
a la precisión de un modelo computacional, como el paso de tiempo requerido para una
simulación.

Indicadores de calidad del modelo

La calidad de un modelo no debe confundirse con la calidad del diseño que representa
el modelo. Por ejemplo, uno puede tener un modelo de diseño asistido por computadora
de alta calidad de una silla que represente con precisión el diseño de la silla, pero el
diseño en sí puede ser defectuoso, de modo que cuando uno se sienta en la silla, se
deshaga. Un modelo de alta calidad debe proporcionar una representación suficiente
para ayudar al equipo de diseño a evaluar la calidad del diseño y descubrir problemas
de diseño.
La calidad del modelo a menudo se evalúa en términos de la adherencia del modelo a
las pautas de modelado y el grado en que el modelo aborda su propósito previsto. Los
ejemplos típicos de pautas de modelado incluyen convenciones de nomenclatura,
aplicación de anotaciones de modelo apropiadas, uso adecuado de construcciones de
modelado y consideraciones de reutilización del modelo. Las pautas específicas son
diferentes para los diferentes tipos de modelos. Por ejemplo, las pautas para desarrollar
un modelo geométrico utilizando una herramienta de diseño asistida por computadora
pueden incluir convenciones para definir sistemas de coordenadas, dimensionamiento
y tolerancias.

Métricas basadas en modelos

Los modelos pueden proporcionar una gran cantidad de información que se puede
utilizar tanto para las métricas técnicas como de gestión para evaluar el esfuerzo de
modelado y, en algunos casos, el esfuerzo general de ingeniería de sistemas (IS).
Diferentes tipos de modelos proporcionan diferentes tipos de información. En general,
los modelos proporcionan información que permite:
 evaluar el progreso;
 estimar el esfuerzo y el costo;
 evaluar la calidad técnica y el riesgo; y
 evaluar la calidad del modelo.
Los modelos pueden capturar métricas similares a las capturadas en un enfoque
tradicional basado en documentos para la ingeniería de sistemas, pero potencialmente
con mayor precisión dada la naturaleza más precisa de los modelos en comparación
con los documentos. Las métricas de ingeniería de sistemas tradicionales se describen
en la Guía de métricas para sistemas integrados y desarrollo de productos (Wilbur
2005).
El progreso de un modelo se puede evaluar en términos de la integridad del esfuerzo de
modelado en relación con el alcance definido del modelo. Los modelos también pueden
usarse para evaluar el progreso en términos de la medida en que los requisitos han sido
satisfechos por el diseño o verificados a través de pruebas. Cuando se aumenta con
métricas de productividad, el modelo se puede usar para estimar el costo de realizar el
esfuerzo de ingeniería de sistemas requerido para entregar el sistema.
Los modelos pueden usarse para identificar parámetros críticos del sistema y evaluar
riesgos técnicos en términos de cualquier incertidumbre que se encuentre en esos
parámetros. Los modelos también se pueden usar para proporcionar métricas
adicionales que están asociadas con su propósito. Por ejemplo, cuando el propósito del
modelo es apoyar la formulación y evaluación del concepto de misión y sistema,
entonces una métrica clave puede ser el número de conceptos alternativos que se
exploran durante un período de tiempo específico.

Referencias
Trabajos citados
Friedenthal, S., A. Moore, R. Steiner, and M. Kaufman. 2012. A Practical Guide to SysML: The
Systems Modeling Language, 2nd Edition. Needham, MA, USA: OMG Press.

Wilbur, A., G. Towers, T. Sherman, D. Yasukawa, and S. Shreve. 2005. Metrics Guidebook for
Integrated Systems and Product Development. Seattle, WA, USA: International Council on
Systems Engineering (INCOSE). INCOSE-TP-1995-002-01.

Referencias primarias
Friedenthal, S., A. Moore, R. Steiner, and M. Kaufman. 2012. A Practical Guide to SysML: The
Systems Modeling Language, 2nd Edition. Needham, MA, USA: OMG Press.

Wilbur, A., G. Towers, T. Sherman, D. Yasukawa, and S. Shreve. 2005. Metrics Guidebook for
Integrated Systems and Product Development. Seattle, WA, USA: International Council on
Systems Engineering (INCOSE).

INCOSE-TP-1995-002-01. Accedido el 13 de abril en:

https://www.incose.org/ProductsPublications/techpublications/GuideMetrics

Discusión de SEBoK
Por favor, proporcione sus comentarios y comentarios sobre el SEBoK a continuación. Deberá
iniciar sesión en DISQUS utilizando una cuenta existente (por ejemplo, Yahoo, Google,
Facebook, Twitter, etc.) o crear una cuenta DISQUS. Simplemente escriba su comentario en el
campo de texto a continuación y DISQUS lo guiará a través de los pasos de inicio de sesión o
registro. Los comentarios se archivarán y se utilizarán para futuras actualizaciones de SEBoK.
Si proporcionó un comentario que ya no está en la lista, ese comentario ha sido adjudicado.
Puede ver la adjudicación de los comentarios enviados antes de SEBoK v. 1.0 en la Revisión y
Adjudicación de SEBoK. Los comentarios posteriores se tratan y los cambios se resumen en la
Carta del Editor y en Reconocimientos e Historial de lanzamientos.

Si desea realizar ediciones en este artículo, recomendar nuevo contenido o hacer

comentarios sobre el SEBoK en su conjunto, consulte el Sandbox de SEBoK [1].