《Proceedings of the Design Society》：Navigating the landscape of MBSE methodologies: a comparative study of ISO 15288 technical process coverage
编辑推荐：
该研究比较了九种基于模型的系统工程（MBSE）方法论与ISO 15288:2023标准在技术过程覆盖率方面的对齐程度，评估内容包括利益相关者定义、利益相关者需求、系统需求、架构、设计、验证与确认等技术过程，同时关联了可追溯性（Traceability）和定制化
该研究比较了九种基于模型的系统工程（MBSE）方法论与ISO 15288:2023标准在技术过程覆盖率方面的对齐程度，评估内容包括利益相关者定义、利益相关者需求、系统需求、架构、设计、验证与确认等技术过程，同时关联了可追溯性（Traceability）和定制化（Customisation）两项比较标准。结果表明，系统需求定义和系统架构定义是系统工程（SE）的共同核心组成部分。
系统工程（SE）是一种跨学科的系统设计、实现与管理方法，国际系统工程协会（INCOSE）与国际标准化组织（ISO）联合制定的ISO 15288:2023标准是该领域的核心文件，其技术过程涵盖系统全生命周期与系统开发。在SE的 broader 学科中，基于模型的系统工程（MBSE）通过模型中心化的过程替代文档中心化的方法，成为实现系统开发概念的重要实践形式。MBSE包含三大支柱：建模语言、建模工具和方法论。随着MBSE方法论种类日益增多，该领域呈现出碎片化态势，给实践者和研究人员带来困惑。在此背景下，研究人员以ISO 15288:2023的技术过程为比较基准，探究OMG引用的MBSE方法论与该标准的对齐程度，以回答"MBSE方法论在技术过程层面如何与ISO 15288:2023对齐并支持该标准"这一研究问题。
该研究首先梳理了现有文献，发现既往研究或仅比较有限数量的方法论与ISO 15288:2023标准的关系，或使用未明确扎根于该标准系统开发过程的比较框架，且多关注方法论特性（如工具集成、易学性）而非与标准生命周期过程的对齐度。因此，当前MBSE方法论与ISO 15288:2023规定过程的对接程度尚不明晰。为填补这一研究空白，研究人员直接以ISO 15288:2023的系统开发技术过程为基准，对九种MBSE方法论进行了系统比较。
研究人员采用的技术方法主要包括以下关键环节：首先，构建基于ISO 15288:2023的比较网格（Comparison Grid），涵盖与该标准系统开发直接相关的技术过程，包括利益相关者识别（Stakeholder Identification）、利益相关者需求（Stakeholder Needs）、系统需求（System Requirements）、系统架构（System Architecture）、系统设计（System Design）、系统分析（System Analysis）以及验证与确认（Validation and Verification, V&V），并附加可追溯性和定制化两项比较标准。其次，采用三点量表（无覆盖、部分覆盖、完全覆盖）对各方法论进行评分，以确保比较的清晰性和易用性。在方法论选取方面，研究人员从OMG网站和Wilke等（2024）列出的22种方法论中，依据文档权威性、公开可获取性、版本时效性、结构完整性等标准筛选出九种方法论，分别为：OOSEM、SysMOD、ARCADIA、Harmony aMBSE、MagicGrid、OPM、SPES_XT、LITHE和CONSENS，每种方法论选取单一权威文档作为分析依据。
研究结果部分，研究人员按照覆盖率从高到低的顺序呈现了九种方法论的比较结果。
在定制化（Customisation）方面，仅SysMOD和ARCADIA两种方法论的文档明确涵盖了该特性。例如，SysMOD的文档指出，在方法论经过裁剪后，员工需接受针对裁剪后具体实践的培训。其余七种方法均未提及定制化，因此在比较网格中标记为无覆盖。该结果表明，多数MBSE方法论缺乏根据具体系统开发需求进行调整的机制，而这是ISO 15288:2023所强调的重要特性，也是影响MBSE更顺畅采纳的关键因素之一。
在可追溯性（Traceability）方面，研究人员评估了各方法论是否明确建立系统开发各阶段之间的联系。OOSEM、SysMOD、ARCADIA和MagicGrid的文档明确提及了系统开发各阶段之间的链接，因此获得完全覆盖评分。SPES_XT的文档明确了其工件（Artefacts）之间的关联，并详细说明了需求与架构定义之间的链接，同样获得完全覆盖评分。Harmony aMBSE的文档仅提及利益相关者需求与系统需求之间的关联，但未明确提及其他链接，故评为部分覆盖。OPM的模型具有连续性，元素之间相互链接并不断添加，但文档未明确提及SEBoK定义中"主从关系"的概念，因此也评为部分覆盖。LITHE和CONSENS的文档未提供系统开发技术过程之间链接的详细说明，故标记为无覆盖。
在系统开发技术过程方面，各方法论的覆盖情况呈现显著差异。ARCADIA、OOSEM和SysMOD的文档涵盖了所有考虑的技术过程，其中ARCADIA和OOSEM在利益相关者识别方面仅为部分覆盖，因为该过程是隐含的而非明确提及的——由于利益相关者需求推导需要列出利益相关者，这种隐含的识别被视为部分覆盖。Harmony aMBSE在利益相关者识别方面获得完全覆盖，这得益于其初步步骤；MagicGrid则为部分覆盖，因其文档隐含了对利益相关者列表的需求。MagicGrid详细说明了利益相关者需求的收集及其向系统需求定义的转化，而Harmony aMBSE以项目初始化开始，寻求利益相关者的用例。两种方法论在此过程后均进入系统架构阶段。Harmony aMBSE文档明确指出应从系统工程师过渡到专业工程师进行系统设计；MagicGrid则通过详细描述每个子系统来构建系统架构，但未明确解释系统设计过程，虽要求向专业工程师过渡但未提供细节。两种方法论均未包含候选方案比较，但Harmony aMBSE包含了一个其他方法论或比较网格中未出现的系统架构折中分析步骤。
对于CONSENS和LITHE方法论，其文档均从系统需求定义开始，但未说明其输入来源，同时涵盖了系统架构。CONSENS的部分模型使其能够设计系统的外形，从而覆盖系统设计；LITHE则用于开发硬件和软件单元。这两种方法论在候选方案比较方面存在分歧：LITHE的文档将候选系统方案的比较纳入架构定义，而CONSENS的文档未明确提及此步骤。在V&V方面也存在差异：CONSENS使用多个部分模型来验证系统是否按照其他部分模型构建——这是其方法论解释中隐含的；而LITHE在系统设计过程中进行验证，在部署前进行确认。
OPM和SPES_XT的文档表明这两种方法论的范围较窄，均从系统需求开始，随后进入系统架构。SPES_XT与CONSENS概念相似，通过多个视图形成包含需求和架构定义的模型。在OPM文档中，利益相关者首先被隐含列出，然后使用其自定义建模语言对象过程语言（Object-Process Language）构建系统需求和系统架构。该自定义语言简化了仿真，使系统逻辑更易于理解。在系统设计方面，OPM未予覆盖，而SPES_XT覆盖了软件设计但未覆盖系统的物理部分。关于V&V，OPM文档未明确提及，但其模块的逻辑仿真及它们之间的可视化链接有助于模型创建后的早期验证，因此评为部分覆盖；SPES_XT的文档则未隐含或明确地提及V&V。
综合比较结果表明，ARCADIA、OOSEM和SysMOD在所有考虑的技术过程中表现突出，而其他方法论如Harmony aMBSE则存在覆盖不足。研究还发现，除OPM外，较早发布的方法论往往比近期发布的方法论具有更好的覆盖率。
在讨论部分，研究人员将上述结果与既有研究进行了对话。研究发现仅三种方法论覆盖全部系统开发技术过程，这与Di Maio等（2021）关于OPM和ARCADIA的发现以及Abdelrazik等（2019）关于Harmony SE和OOSEM的研究结论一致。与Wilke等（2024）的比较显示，除"物理结构"标准与"系统设计"标准的差异外，其他结果相似。在用户指导方面，SysMOD因其对各步骤的详细说明而突出，包括每阶段所需文档或模型、参与人员及产出工件；MagicGrid、ARCADIA和OOSEM也提供了包含示例和教程式说明的具体指导；而CONSENS和LITHE的文档因篇幅限制仍停留在理论层面。从方法论结构来看，MagicGrid、LITHE、OPM和SPES_XT采用递归方法，进行详细而重复的系统分解；而ARCADIA和Harmony aMBSE则以更线性的方式推进开发步骤。
该研究对学术界具有重要意义：所有方法论均覆盖系统需求和系统架构定义，这支持了Hermelingmeier等（2025）关于这些过程构成MBSE共同核心组件的观点。然而，共同核心组件数量有限，表明INCOSE在全生命周期实施SE的愿景与当前MBSE方法论中SE实施程度之间可能存在脱节。此外，较早的方法论（除OPM外）往往具有更好的覆盖率。该研究可作为进一步比较和改进现有MBSE方法论的起点。
对工业界而言，MBSE方法论是MBSE实施的重要组成部分，是连接SE高层指导原则与MBSE具体操作方式的桥梁。INCOSE认可多种方法论但不作特别推荐，这增加了MBSE采纳的难度。INCOSE 2020年的MBSE调查表明，方法论构成MBSE采纳的首要障碍。该研究补充了Weilkiens等（2016）和Wilke等（2024）的工作，为不同方法论的系统开发技术过程覆盖率提供了概览比较。需要指出的是，方法论并非MBSE的唯一支柱，工具选择和建模语言选择会相互制约。例如，Harmony aMBSE要求使用IBM Rhapsody工具和SysML v1建模语言；选择ARCADIA则需使用Capella软件及其自有建模语言。尽管SysML v2的引入可能改变系统开发过程中的产出物，但方法论对技术过程的覆盖率预计变化甚微。当前评估的所有方法论均基于SysML v1，而向SysML v2的过渡可能需要数年时间，SysML v1仍将在维护企业遗留模型方面保持相关性。
研究局限性方面，为确保比较的公平性和可重复性，研究人员有意仅考虑权威来源的方法论文档，这可能无法捕捉各方法论的最新更新。例如，MagicGrid存在单独阐述V&V的文献，但因未被纳入该方法论权威著作而未在比较网格中体现。此外，该研究基于文献，文本分析存在解释空间；为限制主观性并确保一致性，研究人员对过程和标准使用了明确定义。研究人员也承认，文献中描述的方法论与MBSE实践者的实际体验可能存在差异，因此该文献研究可通过实践者的实证研究加以补充。
研究结论部分指出：该研究基于权威来源发布的文档——每种方法论使用一份文档——比较了九种MBSE方法论与ISO 15288:2023在技术过程覆盖率方面的对齐程度。所有方法论与标准的共同点是系统需求定义和系统架构定义，这两者似乎是MBSE的共同核心组件。这与INCOSE的系统开发愿景形成对比——INCOSE认为利益相关者需求和系统设计也应是核心组件。根据比较网格，分析的九种MBSE方法论中仅有三种与系统开发标准ISO 15288:2023对齐并支持该标准，这三种方法论是SysMOD、OOSEM和ARCADIA。该研究是一项初步研究，旨在通过ISO 15288:2023的视角促进对MBSE方法论景观的理解。
