系统工程

学生在手机上看见“预约成功”，走到教室门口，门却没有打开。先把本例的成功含义限定清楚：预约软件已保存这次预约，接口返回成功；它没有承诺门锁、供电或现场处置都正常。若交付目标是“有权限的学生能够使用预约的教室”，只验一个软件接口，显然还缺几段关系。

前面几节分别解释了计算机、程序、网络和媒体。系统工程（Systems Engineering，SE）把这些能力放回同一个目的、环境与生命周期里：系统包含什么，谁使用和保障它，怎样提出方案，怎样取得需求与验证证据？本节按概述、工程方法、生命周期、基于模型的系统工程四部分展开。阶段、方法和模型各有职责，阅读时先确认它们在回答哪个问题。

2.8.1 系统工程概述：先画清交付对象

若关注的是预约软件，门禁平台可能是外部服务，双方通过接口协作。若关注的是校园教室使用服务，预约软件、门禁控制器、身份信息、操作人员、现场流程和供电设施都可能进入系统边界。这里的边界由研究目的与职责决定，不能由“它是不是计算机零件”代替判断。同一个对象，对一个团队是系统，对另一个团队可能是系统元素或运行环境。

教材把系统理解为相互作用的元素为特定目的组织起来的组合。元素可包括硬件、软件、数据、人员、流程、设施与其他支持对象。软件本身也有结构和运行机制，但完整教室服务还要处理人、设备和环境之间的接口。2.1的单机组成和2.4的门禁控制器分别是不同观察范围的入口。

再把门口问题写成四类对象，就容易看懂教材的“结构、要素、信息和反馈”。门锁、控制器、人员是要素；它们怎样连接、分工和依赖是结构；预约授权、开门指令和状态记录是信息；取得执行结果，再据此调整授权处理、维护或方案，才形成反馈。只有记录一条日志，还不能证明结果已被用来调节系统。需求规定要实现什么，专业知识帮助分析，文档承载记录；它们不能不看空位就代替这四个词。

系统工程从整体协调出发，把自然科学、社会科学、技术和组织方法结合起来，考虑规划、设计、制造、试验、使用与退出。教材用“最优规划、最优设计、最优管理、最优控制”表达目标。实际方案先说明目标和约束：更方便的通行、更少的维护负担、成本与风险可能相互牵制，不能只把某个局部指标推到最大就声称全系统最优。

系统之系统（System of Systems，SoS）强调多个系统相互作用形成单个系统不能独立实现的能力。Maier 的刻画尤其关注成员的运行独立性与管理独立性：成员能够独立提供有用服务，也保有自己的管理目标，再通过协同提供更大的能力。独立运营的图书预约系统、门禁服务和校园服务能否构成所讨论的SoS，仍要声明成员、职责与协同能力；仅仅共享定位服务或把一个控制器画成多个子模块，不能据数量判定。教材“元素本身是系统”提供简化起点，独立性与协同关系让判断更具体。

2.8.2 系统工程方法：一项工作可以有三个位置

工程团队在运行期发现门口故障，仍要澄清问题、确定恢复目标、提出候选处置、分析约束并作决策。做这些工作，不会让系统自动倒退到研制阶段。霍尔（Hall）的三维结构把“项目进程”“解决问题的逻辑”“所用专业知识”同时放到一项工作上。

系统综合提出候选方案，系统分析研究候选的效果、代价与可行性，优化寻找或改善满足约束的方案，决策确定采用的方案，实施把决定落实。这里“先综合后分析”解释霍尔所列步骤中的对象，不禁止在明确问题时分析日志和现状；它也不把“系统综合”直接等同于后面的“综合集成法”。

旧练习问“时间维不包括”，需要对这套七阶段核成员：更新在名单末尾，评估没有独立列作时间阶段。评估活动仍可在不同阶段发生。同样，旧题在指定时间维语境下，把长远目标的规划与“提出具体的计划方案”的拟定相区分；日常说一句“我拟订一个维修方案”，还不足以判定整个项目处于时间维第二阶段。先看题目指定的模型，再看动作所针对的对象。

目标存在分歧时，先把观点变成可讨论的模型

技术人员可能认为门开得快就完成任务，管理人员还关心权限审计，学生关心遇到故障能否找到处置人。若连“好方案”都未达成共同理解，直接给一个优化目标，会把部分人的诉求藏起来。切克兰德（Checkland）的软系统方法通过表达问题、建立有观点的概念模型，与现实比较和学习，寻找现实可行的改善。软系统、硬系统描述问题与方法的特点，不是软件系统、硬件系统的分类。

按本教材七步骤，先认识问题，收集现状、主体及关系；用根底定义明确所讨论活动的目的与基本观点；再建立概念模型，表达依该定义需要哪些相互关联的活动；把模型和现实比较及探寻，听取相关人的意见；选择可接受且可行的改善；完成设计与实施；最后评估与反馈，必要时修改问题描述、根底定义或模型。这里的反馈有明确的返回对象。

例如，模型要求有“异常通行请求的责任人和处置活动”，现实却无人接手。改善可以是明确值班责任、接口状态和处置流程，再观察效果。若改变条件，故障只是一个已明确定义的接口字段错误，各方目标、评价准则都已一致，就可以直接分析与修复该技术问题；不必仅凭“有人参与”强制套完整软系统流程。复杂项目又可能在技术分析旁保留观点协调，两种关注能够结合。

让不同职能、资料和观点及早协作

教材还列并行工程、综合集成法和WSR系统方法。它们都涉及协作，但解决的困难不同。把五种方法称作五个互斥“系统类型”，会误以为选了一种便不能使用另一种。

并行工程让产品与相关过程一起被考虑。安装人员指出设备接线和现场条件，维护人员指出更换与故障诊断需求，这些反馈能够影响尚未定型的设计。项目小组各自安排工作，同时定期或随时交换信息、协调问题；信息系统可支撑协作，教材提到计算机集成制造技术（CIM）。质量、成本、开发与上市周期是它追求的目标，实际改善仍需具体项目证据。

理解综合集成法还要看教材的系统分类：子系统较少且关系单纯是简单系统；数量巨大称巨系统，种类与关联较简单可称简单巨系统；种类多、有层次且关联复杂则是复杂巨系统；与环境进行物质、能量、信息交换又体现开放性。规模、复杂性与开放性不能由“设备很多”一个条件全部推出。开放复杂巨系统还具有多层交互、巨量、层次以及进化和涌现等特点，整体行为可能不能仅由单个部分直接说明。教材强调整体、相互联系、有序与动态原则，并以专家群体、数据/信息、计算机/网络构成综合集成研讨体系。

WSR用“懂物理、明事理、通人理”概括实践准则。门禁供电和设备能力是物理条件，如何安排安装、授权与维护是事理，谁担责、谁受影响、如何接受变化是人理。自然科学方法、运筹和管理方法、关于关系/情感/习惯/知识/利益的理解分别有用，实际同一行动常涉及三方面。教材一般工作过程为理解意图、制定目标、调查分析、构造策略、选择方案、协调关系、实现构想；顺序按情境调整，协调关系贯穿过程，还要协调物/事/人、投入/产出与成效，不能只在倒数一步沟通。

2.8.3 生命周期：阶段名称背后有不同的目的

把工程从开始看到退出，教材又给出七个一般生命周期阶段。这套名称与霍尔时间维不同，不能见到数字七就互换。阶段是组织理解当前目的与作进入下一阶段决定的框架，具体技术过程又可能贯穿多个阶段；生命周期应按系统及环境选择和剪裁。

本书引用的ISO/IEC 15288:2008有历史身份，已由后续版本替代；官方当前目录列ISO/IEC/IEEE 15288:2023，发布于2023年5月。现行公开摘要允许过程迭代、并发以及向系统元素递归应用，并不指定唯一生命周期模型、开发方法或建模技术。因此下表保留本教材的七阶段，不把它说成现行标准强制统一的七阶段。本轮只核官方公开摘要与目录，没有把付费标准全文当作已读来源。

原练习的难点是“细化需求”少写了对象。概念阶段细化利益攸关者需求，开发阶段细化系统需求并创建方案描述。前者关心用户及相关方要解决什么问题，后者把这些诉求转换成可落实、可检查的系统要求。若没有单列探索性研究，教材还让概念阶段识别、明确并记录利益攸关者需求；不能见到“识别”就断定名称必须改为探索阶段。只看“需求”二字，无法判断是哪一阶段。

这里以产品验证（Verification）和产品确认（Validation）区分比较基准：前者取得符合规定需求的证据，后者检查预期用途、环境与用户及相关方的期望。例如，按接口规格检查授权状态传送正确，是规定要求的符合性问题；在预期环境中确认学生能完成预约教室的使用目标，是使用适用性问题。测试、分析、检查和演示均可提供相应证据；模型、原型和最终系统也可有相应活动，不能只做代码单元测试便宣布整个服务已确认，或把所有V&V都留在交付后。需求本身同样需要确认其清楚、正确、完整、可达成并符合相关方期望，不能把这两栏理解为“确认永远不能检查需求”。

系统使用期间，维修与更新配置可能同时发生，所以使用和保障不是必须首尾接续的两段。生产、使用和保障中的更改还可能影响需求、接口与性能，要评估影响并重新取得受影响的证据。退役是最后列出的阶段，退出要求却应在早期定义系统时考虑；“到最后再想保留什么数据和怎样退出”会增加后来的约束和风险。

同样的阶段目的，可以采用不同推进方法

计划驱动方法为需求、设计、构建、测试和部署组织规程，重视文档完整性、追溯和验证。渐进迭代式开发（Iterative and Incremental Development，IID）先提供初始能力，评估假设与反馈，再逐步演进；客户需要尚不清晰或新技术仍待探索时，这种安排可以帮助较早取得认识。两者的差别不能缩成“前者完全不改，后者什么都不计划”。

精益系统工程把价值交付和消除浪费贯穿组织工作。反复手工转录已一致的接口资料可能是浪费，必要的联调和风险检查却不能只因耗时而删掉。敏捷强调尽早持续交付、响应变化、业务与开发协作、技术和设计质量、自组织及定期改进。对整个系统应用这些原则时，还要考虑硬件、现场部署和风险约束，不能把软件中很短的改版周期直接套到所有实体设备。

假设首次试点只开放一间教室，团队通过使用反馈完善后续能力，这是增量交付的自编情境；每次交付仍要检查相应的授权、接口和处置要求。若改成涉及多方设备供货与安装的统一上线，计划、里程碑和证据协调的重要性会上升，但局部子系统仍可迭代。不同推进方法与不同阶段目的能够同时描述这个项目。教材对小型、不太复杂系统的IID倾向属于该段概述，不能升级成“大系统禁止任何迭代”的普遍规则。

2.8.4 MBSE：把信息关联起来，还要选择怎样建模

把需求写在文档甲，设备接口写在表乙，流程画在图丙，修改一种授权状态后，就要找到所有受影响处。基于模型的系统工程（Model-Based Systems Engineering，MBSE）系统地用模型支撑需求、分析、设计、验证和确认，并贯穿后续生命周期。它仍遵循分解、综合和系统协调的思路；变化的是如何表达、关联、分析和维护工程信息。

系统建模语言 SysML（Systems Modeling Language）帮助不同学科表达系统。教材介绍的SysML基于UML子集重用与扩展，及其九种图的分类属于SysML v1语境；不要把这段历史介绍当成所有版本都沿用相同元模型和图集的保证。2.6的模型、图与视图已经说明，一张图只是对模型信息的一种呈现，图数量不直接证明建模完整。

作为版本补充，OMG的SysML v2.0正式采用日期为2025年9月；本轮读到的语言规范文件封面为2026年3月。v2扩展KerML，并提供文本与图形记法；它不能继续笼统称作UML profile。下面九图沿教材v1展开，版本变化不要求把本节扩成完整v2语言教程。

教材把需求分析、功能分析与分配、设计综合三类活动与常用图作对应。它帮助我们选择表达任务，不规定一种图只能在一个阶段使用，也没有把整个系统工程过程限成三个固定阶段。

例如，调整门禁接受的授权状态，模型中的需求、消息、状态、接口和验证项可能都受影响。关联与追溯帮助找到这些关系，分析和仿真可以检查部分条件，实物或运行环境中的证据仍要按目的取得。模型库支持的数据交换，也不自动保证任何两个工具无损交换；模型假设与交换格式需要核对。

按教材，建模思路与工作流程应结合组织特点先探索、试点，再推广。选择一种语言和工具后，仍要决定模型边界、分解粒度、需要的行为和约束、怎样评审及维护关联。模型可以成为主要的信息载体，文档依然能用于沟通、规格、说明和记录；“模型驱动”不能被简化成“取消文档”。

回到门口：先确定完整服务的边界，才知道缺哪项元素或接口；时间阶段标明当前目的，逻辑与工程方法组织我们怎样处理问题，模型表达并关联设计和证据。改变一个条件时，知道应改的是职责、阶段安排、方法还是模型信息，就能避免把所有名称堆在一起。下一节2.9系统性能再讨论：这些方案要在什么负载、边界和指标下测量与比较。