本文讨论了使用基于模型的系统工程方法和框架对系统和支持方面的功能进行集成建模。系统工程的支持方面包括:
- 工程管理
- 项目管理
- 需求工程与管理
- 风险建模、分析和管理
- 质量保证、测试、验证和确认
- 系统集成与使用
- 分析“-ilities”(例如,可靠性、可用性、可维护性、安全性和安保 (RAMSS)、可制造性、可扩展性、稳健性、弹性、灵活性和可演化性)
这些方面可以涉及物理方面,也可以涉及核心系统模型的功能、结构、行为、社会和环境方面。 文章主要关注三个方面:
- 项目和工程管理
- 风险建模、分析和管理
- 需求定义和管理
背景
基于模型的系统工程方法认为系统模型不仅仅是对系统的简单描述; 该模型是捕获、表示和集成上面列出的各个系统方面的中心通用基础。 该模型对于系统的设计和理解以及管理其生命周期和演化至关重要。 建模语言构成了系统标准化、形式化描述的基础,就像自然语言构成人类交流的基础一样。
随着系统逐渐变得更加复杂和多学科,系统的概念建模需要发展,并且对于理解复杂设计将变得更加关键(Dori 2002)。 除了促进客户、设计师和开发人员之间的交流外,概念建模语言还有助于清楚地描述和记录各种领域、系统和问题,并为设计和开发阶段定义要求和约束(Wand 和 Weber 2002)。 各种概念建模方法和框架证明了基于模型的分析的重要性,尽管 事实上 标准出现缓慢。 虽然工程设计的某些学科,如结构分析或电路设计,已经建立了建模语义和符号,但复杂系统和过程的概念建模还没有融合到一个统一的、统一的建模框架上(Estefan 2007)。 挑战不仅在于整合多个方面并支持系统生命周期的各个阶段,还在于捕捉系统的多学科性质,这导致了各种框架的创建。 然而,信息系统分析范式目前是最广泛使用的,这可能是由于需要通过信息密集型应用程序和交互来集成复杂系统。
系统和项目的集成建模
本节讨论系统和项目的集成建模以及项目-系统关系(通常称为项目-产品集成)。 项目管理 和 系统工程 领域 由于理解成功的项目创造了成功的系统,因此在过去的二十年中一直在携手推进。 许多主要的系统工程资源都非常重视项目管理,并将其视为系统工程的关键过程和推动者(INCOSE 2012;NASA 2007;Sage 和 Rouse 2011)。 将系统相关方面和概念集成到项目计划中比将项目相关方面和概念集成到系统模型中更为常见。 因为项目是达到目的的手段,所以它是预期交付系统的过程。 事实上,项目活动通常以其旨在促进的可交付成果(例如,“控制台设计”、“软件开发”、“硬件采购”或“车辆组装”)命名或与其一致。
与这些示例中的每一个相关的特定过程是指项目的不同阶段或阶段,以及它所应用的系统或子系统的不同成熟度级别。 此外,仅在活动名称中包含系统和部件名称并不能真正将系统模型工件与这些活动相关联。 总体而言,实际上不可能推导出与将由项目交付的系统的特定部分或功能相关联的活动集。 项目-产品集成并不简单,因为项目模型和系统模型在传统上是完全不同的并且几乎没有接口。 基于模型的项目系统集成方法遵循以系统为中心的范式,并侧重于将与项目相关的方面和概念合并到核心系统模型中, 与上一段中描述的以项目为中心的方法相反。 这些方面和概念包括进度、预算和资源、可交付成果、工作包、约束和以前的关系。 集成的系统-项目模型应该提供有关项目活动和系统组件和能力的相互影响的有用信息。 集成系统项目建模的一些示例包括:
- 与特定系统组件、特性或能力相关的一组项目活动。
- 执行设计或开发系统特定组件的任务所需的一组资源。
- 负责交付每个系统组件的团队或分包商。
- 系统组件部署活动之间预先存在的依赖关系。
- 与每个系统组件、特性或功能相关的成本。
- 为每个交付、部署、构建、发布或版本协商的系统部分。
工作分解结构 (WBS) 旨在支持在参与项目的个人和组织之间划分项目范围(工作内容)(Golany 和 Shtub 2001)。 WBS 传统上是面向组织或活动的; 然而,它的主要基石之一侧重于可交付成果,它对应于系统、子系统、组件或其中一个或多个的能力或特性。 提倡以可交付成果为导向的 WBS,其中高级元素对应于主要子系统,因为它可能使 WBS 更加以产品为导向(Rad 1999)。 项目规划和系统建模的集成方法(Sharon 和 Dori 2009)使用对象过程方法(OPM)将系统模型与项目的 WBS 合并(Dori 2002)。
设计结构矩阵 (DSM) 是增强和分析产品和系统设计的常用方法。 DSM 可以是基于组件的、基于任务的、基于参数的或基于团队的(Browning 2001)。 基于 OPM 的项目-产品模型的 DSM 从统一的 OPM 模型中派生项目活动和系统构建块的混合 DSM,考虑项目活动和系统组件之间的依赖关系,并替换两个单一的和单独的基于组件的和基于任务的 DSM 视图(Sharon、De-Weck 和 Dori 2012)。 底层 OPM 模型确保模型的一致性和可追溯性。 集成的项目-产品 OPM 模型包括图表和等效的自动生成的文本描述。
另一种基于模型的方法 (Demoly et al. 2010) 使用系统建模语言 (SysML) 来创建满足各种系统利益相关者(例如项目/流程经理)需求的各种视图。 该方法包括面向产品和面向过程的视图。
系统和需求的集成建模
需求是描述系统的操作、功能或设计相关方面的陈述。 需求定义和管理是一个重要的 SE 过程,因为它通过定义工程系统的预期功能和性能来启动和促进整个 SE 工作。 与需求相关的几个挑战包括:
- 以结构化、受控的方式定义需求。
- 将这些需求跟踪到系统组件、方面和决策。
- 测试和验证系统是否符合这些要求。
将概念系统模型扩展到包括需求有几个显着的好处:
- 需求通过根据特定需求制定和证明体系结构和设计决策,为系统的体系结构和设计提供基本原理。
- 对内部逻辑以及需求之间的层次结构和依赖关系进行建模,可以识别和消除冗余和矛盾的需求。
- 负责交付各种系统组件的团队和人员通常可以负责满足特定要求。 虽然拥有良好的需求工程的优势是显而易见的,但将需求直接跟踪到特定的系统工件通常是一个挑战,尤其是当需求以整体的、独立于解决方案的方式定义时。
有几种方法可以将需求合并到系统模型中,包括 SysML 需求工程和基于对象过程方法 (OPM) 的需求工程和创作。
基于 SysML 的需求工程
SysML 需求图使得以可视化的方式捕获需求及其之间的关系成为可能,这比传统编辑和管理需求的文本方式更直观。 该图已添加到构成 SysML 基础的基本 UML 图集(Friedenthal、Moore 和 Steiner 2006),而不是原生 UML 图。 可以在 SysML 块定义图中捕获对系统块和满足它们的工件的跟踪需求,该图主要用于捕获系统元素和组件类型之间的关系。 块和需求之间的 < > 链接捕获跟踪。
基于 OPM 的需求工程
对象-过程方法论 (OPM) 是一种方法论和语言,用于复杂系统和过程的概念建模,具有双峰文本和图形表示 (Dori 2002)。 OPM 的文本表示与图形表示相协调; 此外,对象-过程图 (OPD) 中的每个视觉模型构造都由对象-过程语言 (OPL) 中的正式结构化文本语句描述,该语言是自然英语的子集。 OPM 以三种可能的模式促进基于模型的需求工程、创作和规范:
- OPM 可用于生成最初关注需求级别(问题域,而不是设计级别或解决方案域)的概念模型,这有助于基于模型的自动化需求生成(Blekhman 和 Dori 2011)。 需求模型是解决方案中立的,它可以作为一个或多个架构解决方案的基础,以实现需求中指定的功能。
- OPM 可用于生成面向需求的 OPD,其方式类似于 SysML 需求图使工程师能够将需求规范捕获为系统模型的骨架。 用户定义的标记结构关系,例如“被实现”或“分配给”,提供将需求与系统模型功能(转换它们的对象和过程)相关联。这种方法类似于 SysML 需求图;但是,在单独的图表类型中使用独特的符号,需求被无缝地结合到单个系统模型中。
- OPM 可用于通过将文本编写的需求跟踪到系统模型插入和工件来从正式指定的需求生成视觉系统模型(Dori 等人,2004 年)。
将风险整合到系统模型中
风险 是对不确定性的负面或不利影响的表达和衡量。 只要不确定性会导致多种结果,其中一些可能是负面的(不利的),一些可能是正面的,就会存在风险。 一个系统面临来自其他系统或环境的风险,它也可能对其他系统或环境造成风险。 系统具有这样的属性,例如:目标、目的、输入、输出、变量、参数、过程、事件、状态、子系统、接口、机制和方法。 系统脆弱性是系统在这些属性中的任何一个方面受到伤害或负面影响的总可能性。 类似地,系统有害性是系统伤害他人或产生负面影响的总潜力,可以体现在这些属性中的一个或多个中(Haimes 2009)。 基于模型的风险分析 (MBRA) 支持结构化分析和与风险相关的过程控制。 文献中提供了几种基于模型的风险分析方法。 MBRA 目前在信息技术和信息安全领域比在系统工程领域更常见; 但是,其中一些方法通常也适用于复杂系统。 ISO-IEC-IEEE 协作软件开发和运营生命周期标准(ISO 和 IEC 2004)提出了一种并行的 IT 风险管理方法。 这种方法包括六项主要活动: MBRA 目前在信息技术和信息安全领域比在系统工程领域更常见; 但是,其中一些方法通常也适用于复杂系统。 ISO-IEC-IEEE 协作软件开发和运营生命周期标准(ISO 和 IEC 2004)提出了一种并行的 IT 风险管理方法。 这种方法包括六项主要活动: MBRA 目前在信息技术和信息安全领域比在系统工程领域更常见; 但是,其中一些方法通常也适用于复杂系统。 ISO-IEC-IEEE 协作软件开发和运营生命周期标准(ISO 和 IEC 2004)提出了一种并行的 IT 风险管理方法。 这种方法包括六项主要活动:
- 规划和实施风险管理
- 管理项目风险概况
- 进行风险分析
- 执行风险监控
- 进行风险处理
- 评估风险管理流程
这些活动同时执行,相互影响和提供反馈,并与其他软件生命周期过程交互,例如技术管理和设计过程(ISO 和 IEC 2004)。
CORAS 方法(Fredriksen 等人 2002;den Braber 等人 2006;Lund、Solhaug 和 Stølen 2011)是一种用于 IT 安全风险建模和评估的 UML 衍生工具。 该框架主要由 UML 用例 (UC) 图组成,并针对误用情况进行了扩展。 为了捕捉风险来源、影响和结果,在 UC 符号中添加了额外的符号(例如,“坏演员”图标、风险资产的钱袋子)。 例如,滥用图表可能包括因信息盗窃和不忠员工的分发而导致专有技术丧失法律保护的风险。 对导致上述风险的安全策略不足的风险源的处理在单独的处理图中进行了说明。
基于组件的系统的定量风险评估方法(Grunske 和 Joyce 2008)支持使用模块化攻击树进行组件漏洞分析和规范。 此外,它还提供攻击者分析,从而支持使用计量经济学方法来应对风险。 该方法利用 SysML 作为其基础语言,特别是 SysML 块定义图和参数图,以便捕获参数关系和约束作为定义风险概况的一种手段。
系统理论事故模型和过程 (STAMP) 是一种用于安全系统和组件设计的方法 (Leveson 2011)。 STAMP 将安全问题重新表述为控制问题,而不是可靠性问题。 STAMP 针对以安全为导向的系统工程和设计以及避免和减轻危险进行了优化,特别是在复杂的社会技术系统中。 还提出了基于模型的 STAMP 改编(Leveson 2004)并在各种安全关键和任务关键系统中实施,包括飞机防撞系统 (CAS) (Leveson 2004) 和弹道导弹防御系统 (Pereira, Lee,和霍华德 2006)。 面向风险的系统工程 (ROSE) (Mordecai and Dori 2013) 是一种基于对象过程方法 (OPM) 的方法,用于将风险集成到系统模型中。 以系统为中心, ROSE 负责在核心系统模型之上并与核心系统模型同步捕获风险层和方面,同时改进并使其免受捕获的风险的影响,并通过设计生成系统稳健性和弹性以响应各种风险构成场景。 风险处理元模型包括设计阶段的风险缓解和运营阶段的风险响应。
|