3. Hexagon数字制造项目常见交付物清单
在Hexagon数字制造项目中，验收能否顺利通过，往往不取决于现场演示时系统跑得多流畅，而取决于交付物是否完整、可追溯、可复用。软件许可、配置文档、二次开发代码、培训材料、测试报告、竣工图纸与数据字典，这七类交付物构成了从“系统能运行”到“项目可移交”的完整证据链。它们分别回答不同的问题：许可回答“能不能合法用”，配置文档回答“系统被改成了什么样”，二次开发代码回答“定制逻辑怎么维护”，培训材料回答“人会不会用”，测试报告回答“是否达到验收标准”，竣工图纸回答“现场与系统如何对应”，数据字典回答“数据从哪来、到哪去、含义是什么”。
下面按交付物类型逐一说明其构成与要求，并在关键处给出可直接参考的示例。
软件许可：先确认授权边界，再谈功能验收
Hexagon产品线通常涉及设计、测量、仿真、质量等多个模块，许可形式包括永久许可、订阅许可、网络浮动许可和节点锁定许可。交付时不能只给一张授权文件截图，而应形成“许可清单+授权文件+部署记录”的组合。许可清单至少包含：产品名称与版本、许可类型、授权数量、绑定方式（MAC地址、加密狗或服务器）、有效期、许可服务器地址与端口、对应模块功能范围。例如某项目采购了网络浮动许可，许可服务器部署在 192.168.10.21，端口 27000，则部署记录中应写明该地址，并附上客户端环境变量或配置文件中的指向设置。
验收时重点核对三件事：许可数量是否与合同一致；许可是否覆盖实际使用的模块；许可服务器是否具备冗余或恢复方案。若许可为订阅制，还需记录续订责任人和到期提醒机制，避免项目移交后因许可过期导致系统停摆。
配置文档：把“改了什么”变成可复现的说明
配置文档是验收中最容易被低估、却最容易在后期引发争议的交付物。它不应只是截图堆砌，而应包含配置基线、变更记录和恢复方法。典型结构包括：系统架构与部署拓扑、数据库连接参数、用户与权限矩阵、工作流与审批规则、模板与报表配置、接口与集成参数、环境变量与启动参数。
以权限矩阵为例，建议用表格明确“角色—模块—操作—数据范围”四要素。例如“质检员”角色对“测量任务”模块具有“查看、录入”权限，数据范围限定为“本车间”，而“工艺工程师”具有“查看、编辑、发布”权限，数据范围为“全厂”。配置文档还应记录每次变更的日期、变更人、变更原因和回滚方式。若系统支持配置导出，应同时交付导出文件，并注明导入命令或操作路径，使配置可在测试环境复现。
二次开发代码：可编译、可追溯、可交接
当标准功能无法满足业务需求时，项目会涉及二次开发，常见形式包括插件、脚本、接口适配、报表扩展和自动化任务。代码交付不是简单打包一个压缩文件，而应满足以下要求：代码可编译或可解释执行；依赖库版本明确；目录结构清晰；关键函数有注释；与配置文件的对应关系可查；有版本管理记录。
建议交付物中包含一份 README，说明开发环境、编译命令、部署路径和启动方式。例如：
# 构建
mvn clean package -DskipTests
# 部署
将 target/hexagon-ext-1.0.0.jar 复制到
/opt/hexagon/extensions/ 目录
# 配置
修改 config/extension.properties 中的
server.url 与 token 参数同时应提供接口说明或调用示例，尤其是与MES、ERP或测量设备交互的部分。若代码中涉及密钥、令牌或数据库密码，必须从源码中剥离，改由配置文件或环境变量注入，并在交付说明中写明配置位置。验收时应验证代码能在干净环境中重新部署并正常运行，而不是只能在原开发机上运行。
培训材料：面向角色，而不是面向功能菜单
培训材料常见的问题是“把操作手册当培训材料”。验收阶段的培训材料应面向不同角色组织，至少覆盖管理员、关键用户和普通用户三类。管理员材料侧重许可管理、用户与权限、备份恢复、日志排查；关键用户材料侧重业务流程配置、模板维护、异常处理；普通用户材料侧重日常操作、数据录入、结果查看和常见问题。
每份材料应包含学习目标、操作步骤、界面截图、注意事项和练习任务。例如针对“测量任务创建”这一主题，培训材料可给出：登录系统→选择项目→新建测量任务→绑定工件与测点→分配设备→提交审批，并附上“若测点未同步，检查设备连接状态与数据字典映射”的排障提示。培训记录也应作为交付物的一部分，包括培训时间、参训人员、签到表和考核结果，以证明知识已转移。
测试报告：用证据说明“达到了验收标准”
测试报告是验收的核心依据，应覆盖功能测试、接口测试、性能测试和用户验收测试。报告结构通常包括：测试范围、测试环境、测试数据、测试用例、执行结果、缺陷记录、回归结论和遗留问题。测试用例应可追溯到需求或合同条款，避免“测了但不知道测的是哪条要求”。
以接口测试为例，若系统需从MES获取工单，测试用例应写明：输入工单号、预期返回字段、响应时间阈值、异常场景（如工单不存在、网络超时）。执行结果应记录实际返回值、耗时和截图或日志片段。对于未通过项，应明确缺陷等级、修复状态和复测结果。验收会上，测试报告的价值在于让甲方看到“哪些已确认通过、哪些有条件通过、哪些遗留待处理”，而不是一句“整体运行正常”。
竣工图纸：让现场与系统对得上
竣工图纸在数字制造项目中常被忽略，但它直接关系到后期运维和改造。竣工图纸应反映实际部署状态，而不是设计初稿。常见内容包括：网络拓扑图、服务器与存储部署图、设备连接与通信图、工位与测点布置图、机柜与布线图。图中应标注设备型号、IP地址、端口、通信协议和线缆编号。
例如设备连接图应能说明某台三坐标测量机通过何种协议、经哪台交换机、连接到哪台采集服务器。若现场经过变更，图纸必须同步更新，并保留版本号和变更记录。验收时可随机抽取一条链路，按图核对现场实际连接，验证图纸的准确性。
数据字典：统一语言，支撑集成与运维
数据字典是七类交付物中最具“底层支撑”作用的一项。它定义系统中关键数据的名称、编码、类型、长度、取值范围、来源、去向和业务含义。没有数据字典，接口对接、报表开发和问题排查都会陷入“同名不同义”的混乱。
数据字典至少应覆盖：数据库表与字段、接口字段、枚举值、编码规则和主数据。例如“工单状态”字段，字典中应明确：10=已创建、20=已下发、30=生产中、40=已完成、50=已关闭，并说明该字段由MES写入、由本系统读取。对于测量数据，还应说明单位、精度和坐标系约定。数据字典应与配置文档、接口文档和测试用例保持一致，避免同一字段在不同文档中定义冲突。
七类交付物之间并非孤立。配置文档中的接口参数应与数据字典中的字段定义一致；二次开发代码的部署路径应与竣工图纸中的服务器部署对应；测试报告的用例应能追溯到配置文档中的业务规则；培训材料中的操作步骤应与实际配置和代码行为一致。验收时，建议按“合同条款→交付物→验证证据”建立追溯矩阵，逐项确认。对于缺失或不合格的交付物，应明确补交责任人和截止时间，而不是在验收会上临时口头承诺。
最后需要强调，交付物清单不是越厚越好，而是越“可执行”越好。一份能让人按步骤复现配置的文档，胜过一百页截图；一段能编译部署并说明依赖的代码，胜过口头解释；一份能追溯到需求并记录缺陷状态的测试报告，胜过“测试通过”四个字。把七类交付物按上述要求逐项落实，Hexagon数字制造项目的验收与移交才能真正做到有据可依、有迹可循。