仅供个人学习记录

系统工程起因

期望当今系统能力较之前有显著提升。
竞争压力要求系统提升技术先进性：提高性能，同时降低成本及缩短交付周期
能力增长驱动需求增长，包括功能、互操作性、性能、可靠性提升与小型化等。

系统不再是孤立的，而是System of Systems, SoS。
例子：原来移动设备仅提供电子邮件、通信，现在提供互连功能，包括视频、全球定位、社交媒体等。

系统工程过程

系统工程是一种多学科方法，针对不同利益相关方的需求提供综合解决方案。
系统工程包括管理和技术过程，以实现权衡，并降低风险。

系统工程技术图有很多，分析也很全面，这里就不再重复了。

系统工程过程的典型应用

针对书中给的技术图进行展开，并举例解释。以下是一些相对关键的概念：

开展分析是未来理解每位利益相关方的需要，并给出有效性测度和目标值。目标值常用于固定解决空间的边界、评估可选方案、从竞争性方案中识别出解决方案。

规范需求过程中，定义系统边界是一个重要的起点。主体与外部环境的交互需要识别，以划清系统边界和其相关接口的界限。

通过分析为实现目标系统所需完成的工作，可以规范汽车的功能需求。功能需求也包括确定功能的顺序。

系统需求必须能够可追溯且可验证。

设计约束会对解决方案产生影响。通常约束是为了节省时间和成本，但降低约束也可能使成本降低。应当对驱动约束的假设予以确认，并通过分析了解这些约束对设计的影响。

部件的性能和物理需求通过多类分析确定。比如说通过分析得到发动机功率、车体阻力系数、各部件重量等部件需求，从而满足汽车加速这一系统需求。而又类似的，根据燃油经济性、排放性、可靠性和成本等系统需求，通过分析得到各项部件需求。

多个相互矛盾的需求中寻求一个综合平衡的系统设计，需要对系统设计的可选方案进行评估，确定优化解决方案。

系统工程的有效应用需要再聚焦系统总体目标与各利益相关方需要的基础上保持宽广的系统视野，同时关注细节和严密性，保证系统设计的完整性。

多学科系统工程团队

主要讲系统工程师需要参与整个系统生命周期，甚至包括制造和维护。需要专业工程领域知识（如可靠性、安全性、人因等），从而权衡系统设计。

书中划分的系统工程管理团队：
团队主要负责技术管理，含计划与控制（如风险管理、度量、基线管理）
团队划分：需求团队（利益相关方需求分析运行构想）、架构团队（系统、硬件、可靠性、成本分析等）、系统分析团队（可能也就是DFX团队？性能、物理、可靠性、成本分析等）、集成与测试团队（验证计划、程序和测试实施）

系统工程实践标准

书中给出部分标准的分类，包括过程标准、建模方法标准、架构描述与框架标准、建模与仿真标准、元建模与数据交换标准。系统建模标准的更多参考可以看SEBoK。

为了方便个人学习后续可能会使用到，还是记录下来（可能有更新的标准）

过程标准： EIA 632, IEEE1220, ISO 15288, CMMI
建模方法： 结构化分析, 面向对象
架构描述与框架：DoDAF, MoDAF, Zachmann, ISO 52010
建模与仿真标准：IDEF0, SysML, UPDM, OWL, Modelica, HLA, MathML
元建模与数据交换标准：MOF, QVT, XMI, STEP/AP233, OSLC