仅供个人学习记录
建模原则
模型与MBSE方法定义
模型描述的是domain of interest
MBSE方法是指以系统模型作为主要制品来实现全部或者部分的系统工程过程
系统建模目的
模型的用途在系统的整个开发全生命周期中是不断完善的，是通过持续完整的需求来描述的。
- 描述现有系统
- 规范、设计新系统或改进系统：
- 表示一个系统方案
- 规范和确认系统需求
- 保持系统设计一致性
- 规范部件需求
- 维持需求跟踪能力
- 评估系统
- 指导系统设计权衡
- 分析系统性能需求或者其他质量特性
- 验证系统设计满足需求
- 评估需求或设计变更后的影响
- 估计系统成本（如开发成本、生命周期成本）
- 培训用户如何运行维护系统
- 支持系统维护和/或诊断
模型确认
对于分析模型，通过模型静态核查，由领域专家复查输入数据和假设、模型、分析结论等实现确认。在这些数据有效的情况下，通过模型执行，并且与真实世界的结果进行对比，得出分析结果。
验证一个模型是否能满足其预期用途，也需要考虑建模语言的内在能力和限制，这取决于语言是否丰富于精确。比如，一种仅表示过程和/或功能流的建模语言可能并不具备表示系统性能、物理特性和方程的能力。
模型质量标准构建
模型的优劣取决于模型满足其目的的程度；好的设计是基于设计满足其要求的程度，包含质量设计准则
- 目的是否准确定义
- 范围是否充分满足其预期用途
- 模型广度：
- 对满足系统需求的范围进行建模，确定模型的广度
- 模型深度
- 模型深度必须充分，确定了系统设计的层级
- 模型精确度
- 模型精确度必须支持细节要求的层级。如低精度的模型用来分析系统性能，高精度模型包括更多的时间信息、系统性能特点和约束；如在接口建模时，低精度模型可能仅包括数据的定义和流向的起点与终点，而高精度模型则对消息结构、通信协议和详细的通信路径建模。
- 模型广度：
- 是否与模型的范围完全相关
- 模型完整的必要条件是广度、深度、精确度能够与其定义的范围相匹配
- 是否很好地组织
- 是否一致
- 强化约束有助于维护模型一致性，但不能阻止设计的非一致性。如两个独立建模人员各自给同一部件赋予不同的名称，却被模型审核人员视为两种不同的部件而集成
- 是否易理解
- 建模约定是否文档化并在应用中保持一致
- 用于反映核心领域概念及其关系的领域专用词汇表可以更正式地定义出来，它可以本体、概念模型或元模型的形式展现。
- 是否能够自动文档化
- 使用一致性的注释和表述有助于提供增量信息
- 是否精确地反映兴趣域
- 模型的精确性依赖于源信息的质量、源信息适应能力假设的有效性、在模型中提取源信息和假设的程度
- 是否与其他模型集成
基于模型的度量
没怎么细看，也没怎么细讲
基于模型的度量可以回答：设计品质、设计和开发工作进展、完成设计和研发的预计工作量
完成设计和研发的预计工作量
这一部分还是比较有意思
建设性的系统工程成本模型（COSYSMO）用于估计开展系统工程活动所需要的成本与工作量
该模型包括规模与生产率参数，其中规模参数估计工作的程度，生产率因子是估计工作中的实际工作量
规模参数可以根据以下内容的数量来确定：
- 模型元素
- 需求
- 用例
- 场景
- 系统和部件的状态
- 系统和部件的接口
- 系统和部件的活动或运行
- 系统和部件的特性
- 部件类型（如硬件、软件、数据、运行程序）
- 约束
- 测试用例
度量也解释了模型元素间的相互关系，如满足的需求数量、验证的需求数量、实现的用例数量、分配至块中的活动数量、已展开的分析数量。
MBSE规模参数集成于成本模型中，这些参数可以带有复杂性因子。例如用例的复杂性可以根据交互中参与的行动方数量得到。需要考虑的其他因子是相对于新建模型、现有模型重用与修改的数量。
需要经常地收集并确认规模与生产率数据，建立统计充分地数据和成本估计关系，用于支持精确成本估计。
