3. Windchill工程交付物清单设计

在Windchill PLM项目验收阶段，交付物清单不是一份简单的文件目录，而是界定“项目到底交付了什么”的契约性文件。它需要同时满足三类读者的需求：甲方运维团队要据此接管系统，开发团队要据此完成知识转移，验收委员会要据此判断合同范围是否履行完毕。因此，清单设计的关键在于分类清晰、命名可追溯、状态可判定，而不是把所有文件堆在一张表里。

针对典型Windchill项目，建议将交付物划分为六大类：配置文档、二次开发代码、数据模型、接口规范、测试报告、培训材料。这六类分别对应系统的“可配置性、可扩展性、数据基础、集成能力、质量证据、用户能力”，覆盖了PLM系统从建设到运营的完整交接面。

配置文档：从“系统能跑”到“系统可重建”

配置文档最容易犯的错误是只交一份“配置说明Word”。真正可用的配置文档应当包含两部分：一是可导入的配置包，二是配置变更记录。以Windchill的类型管理器为例，交付时应导出TypeDefinition、AttributeDefinition、LifeCycleTemplate、WorkflowTemplate、PermissionRule等对象的XML文件，并附一份配置清单，说明每个配置项对应的业务需求编号。

例如，某项目定义了“零部件”类型，其属性包括物料编码（必填、唯一）、物料名称、规格型号、设计者、创建日期。交付文档中应记录：属性“物料编码”的InternalName为WCTYPE|wt.part.WTPart|com.acme.MaterialCode，数据类型为String，约束为Unique，默认值来源为“编号规则生成器”。这样运维人员在系统重建时，才能准确还原配置，而不是靠记忆猜测。

二次开发代码：源码、编译包与部署说明缺一不可

Windchill二次开发通常涉及Custom Action、JSP页面、Listener、Workflow Expression、REST服务扩展等。交付时不能只给一个.jar包，而应提供：源码工程（含pom.xml或build.xml）、编译后的部署包、部署路径说明、依赖库清单、以及关键类的调用关系说明。

以自定义Action为例，交付清单中应记录：Action类名com.acme.actions.PartReleaseAction，注册位置为custom-action.xml，触发对象为wt.part.WTPart，触发事件为“发布状态变更”，调用的Windchill API包括PersistenceHelper.manager.save()和LifeCycleHelper.service.setLifeCycleState()。同时应附一份“开发环境搭建说明”，包括Windchill版本、JDK版本、MethodServer启动参数、以及wt.properties中需要新增的配置项。

# 示例：custom-action.xml 片段
<action name="ReleasePart">
  <class>com.acme.actions.PartReleaseAction</class>
  <objectType>wt.part.WTPart</objectType>
  <event>STATE_CHANGE</event>
</action>

数据模型：对象、属性、关系与编号规则

数据模型交付物应包含三份核心内容：对象模型图、属性字典、编号规则说明。对象模型图用ER图或类图表达WTPart、WTDocument、WTChangeOrder、EPMDocument等对象之间的关联关系。属性字典以表格形式列出每个对象的属性名称、InternalName、数据类型、是否必填、是否唯一、默认值、可选值范围。

编号规则是数据模型中容易被忽略但极其关键的部分。例如，物料编码规则为“MAT-{分类码}-{6位流水号}”，文档编号规则为“DOC-{部门码}-{年份}-{4位流水号}”。交付文档中应说明编号生成器的实现方式（是Windchill自带Sequence还是自定义Java类），以及并发场景下的唯一性保证机制。

接口规范：报文、字段映射与联调证据

Windchill与ERP、MES、CRM等系统的接口是交付重点。接口规范文档应包含：接口清单（接口名称、方向、协议、频率）、报文结构（请求/响应示例）、字段映射表（源系统字段→Windchill字段→目标系统字段）、错误码定义、以及联调测试记录。

以“Windchill向ERP推送物料主数据”为例，接口采用REST方式，请求URL为/api/v1/materials，请求体包含materialCode、materialName、specification、unit等字段。字段映射表中应明确：Windchill的WTPart.number映射为ERP的MATNR，Windchill的WTPart.name映射为ERP的MAKTX。联调记录中应包含实际请求报文、响应报文、以及异常场景（如物料编码重复、必填字段缺失）的处理结果。

测试报告：从单元测试到UAT的完整证据链

测试报告不是一份“测试通过”的结论页，而应包含：测试策略、测试用例清单、执行记录、缺陷跟踪表、回归测试结果、以及UAT签字页。测试用例应覆盖功能测试、权限测试、工作流测试、接口测试、性能测试等维度。

以工作流测试为例，用例应描述：提交“设计变更申请”→审批人审批→变更执行→变更关闭。预期结果为：变更单状态从“草稿”变为“审批中”再变为“已批准”，相关零部件版本从A.1升版为A.2，且变更历史可追溯。执行记录中应附上系统截图或日志片段，证明状态流转和版本升版确实发生。

培训材料：分角色、分场景、可考核

培训材料应区分管理员、最终用户、开发人员三类角色。管理员手册侧重系统配置、用户管理、权限分配、日志查看；最终用户手册侧重日常操作，如创建零部件、提交变更、查询文档；开发人员手册侧重二次开发环境搭建、API调用、部署流程。

培训材料交付时，应附培训签到表、培训考核记录、以及常见问题FAQ。FAQ应基于实际培训中用户提出的问题整理，例如“为什么我无法编辑某个零部件？”“变更单提交后为什么没有进入审批流程？”每个问题应给出原因分析和解决步骤。

最后需要强调，交付物清单不是一次性文档，而应随项目变更持续更新。每次配置调整、代码修改、接口变更、测试补充，都应在清单中记录版本号和变更说明。只有这样，验收时才能做到“清单有据、文件可查、责任可追”，真正实现从项目建设到运营维护的平稳过渡。