ASPICE项目里，工作产品清单、证据清单和双向追溯矩阵经常被做成三张互相抄写的表：同一个工作产品在清单里写一遍描述，在证据表里再写一遍，到了追溯矩阵又填一次名称和版本。重复维护的根源在于没有区分“应做什么”“实际有什么”“前后是否对得上”这三类信息。本文按这三个问题划清职责边界，给出唯一维护点与变更同步规则，并按项目规模和评估阶段说明如何取舍。
要点总览（TL;DR）
- 工作产品清单回答“应做什么”，定义组织级工作产品类型及其模板、评审与基线要求，是唯一的产品定义源。
- 证据清单回答“实际有什么”，按项目记录工作产品实例的位置、责任人与确认状态，通过标识引用清单条目。
- 双向追溯矩阵回答“是否对得上”，只维护需求与下游工作产品、验证结果之间的关系链接，不复制名称与版本。
- 避免重复维护的核心是单一维护点：定义只在清单写，实例状态只在证据清单写，关系只在矩阵写，其余位置用引用或带出。
- 小项目可合并证据与追溯的展示视图，多项目复用保持清单组织级唯一、证据与矩阵按项目拆分，评估前集中核对覆盖率、双向完整性与状态一致性。
三个工件各自回答什么问题
三个工件服务于不同的管理问题，字段设计也应围绕各自的问题展开。把它们混成一张大表，短期看似省事，长期会让每次变更都要改多处，且难以判断哪一处是准的。
工作产品清单：定义过程应产出什么
工作产品清单是过程定义的组成部分，回答“这个过程中按规定应产出哪些工作产品”。它的维护对象是工作产品类型，而非某个项目的具体文件。典型字段包括：工作产品名称与唯一标识、所属过程域与过程、工作产品类别（如需求规格、设计说明、测试用例、评审记录）、必备或可选、模板位置、责任角色、评审要求、基线要求。清单一旦随组织过程定义发布，就在多个项目间复用，项目层面的差异通过裁剪说明体现，不直接改写清单条目。
证据清单：记录项目里实际有什么
证据清单面向具体项目或具体评估范围，回答“这个工作产品在本项目中以什么形式存在、放在哪里、由谁确认、处于什么状态”。它的记录对象是工作产品实例。典型字段包括：引用工作产品清单条目的标识、项目或版本、实例名称与存放位置、责任人、完成状态、评审或确认记录、基线标识。证据清单不需要重复描述工作产品应该包含什么内容，这些内容由清单条目和模板承担。
双向追溯矩阵：连接前后是否对得上
双向追溯矩阵回答“需求与下游工作产品、验证结果之间是否建立了双向关系”。它维护的是关系，典型字段包括：上游对象标识（如需求、系统需求）、下游对象标识（如设计元素、代码单元、测试用例）、关系类型（实现、验证、派生等）、关系状态、建立人与建立时间。矩阵中的对象以标识引用，名称、版本、描述等信息从被引用对象读取，不在矩阵中另行维护。
三者之间是一对多与引用的关系
一个工作产品清单条目对应多个项目中的多个实例，每个实例在证据清单中有一条记录；一个需求可以追溯到多个下游工作产品和多个测试用例，矩阵中表现为多条关系记录。三条链路都通过唯一标识连接：证据清单引用清单条目，矩阵引用需求与工作产品的标识。理解这层引用关系，是后面所有分工规则的基础。
| 工件 | 回答的问题 | 维护对象 | 典型字段 |
|---|---|---|---|
| 工作产品清单 | 应做什么 | 工作产品类型（组织级） | 名称与标识、所属过程、类别、必备/可选、模板、责任角色、评审与基线要求 |
| 证据清单 | 实际有什么 | 工作产品实例（项目级） | 引用清单条目标识、项目/版本、实例位置、责任人、状态、评审确认、基线标识 |
| 双向追溯矩阵 | 是否对得上 | 对象之间的关系 | 上游标识、下游标识、关系类型、关系状态、建立人与时间 |
同口径差异对照：定义源、实例与关系
把三者放到同一组维度上比较，可以更清楚地看出哪些信息只应存在一处。下表按维护对象与粒度、更新触发时机、责任角色、评估时的使用方式四个维度展开。
| 维度 | 工作产品清单 | 证据清单 | 双向追溯矩阵 |
|---|---|---|---|
| 维护对象与粒度 | 工作产品类型，组织级，粒度到“一类产物” | 工作产品实例，项目级，粒度到“一份具体产物” | 对象间关系，项目级，粒度到“一条追溯链接” |
| 更新触发时机 | 过程定义变更、模板调整、评估范围变化时 | 工作产品创建、评审通过、基线建立、状态变化时 | 需求新增或变更、下游产物建立、验证活动完成时 |
| 责任角色 | 过程工程或质量部门牵头，项目经理参与裁剪确认 | 项目内各工作产品责任人维护，质量角色抽查 | 需求、设计、测试各环节责任人分别建立本环节关系，系统或质量角色核对完整性 |
| 评估时的使用方式 | 作为过程定义与裁剪的依据，说明应覆盖的范围 | 作为抽样取证的索引，按条目定位实际产物 | 作为关系完整性的检查视图，验证前后覆盖与双向一致 |
唯一维护点可以归纳为三条：工作产品的名称、类别、模板、评审与基线要求只在工作产品清单维护；实例的位置、责任人、状态、确认记录只在证据清单维护；对象之间的连接关系只在追溯矩阵维护。任何一处需要展示其他两处的信息时，采用引用或自动带出，不手工抄录。
重复维护通常出现在哪些环节
重复维护往往不是有意为之，而是在几个具体动作中逐步形成的。识别这些环节，才能在规则设计时对症处理。
- 清单与证据表各写一份描述。编制证据清单时，为了让表格“看得懂”，把工作产品的用途、应含内容一并抄入，之后清单更新，证据表未同步，两份描述出现分歧。
- 追溯矩阵中重复填写名称与版本。矩阵单元格里直接写需求标题、设计文档名和版本号，需求改名或升版后，矩阵中的文字与实际对象脱节，核对时需要逐格比对。
- 评审记录与证据状态两处更新。评审通过后，评审记录中写一次结论，证据清单中再手工改一次状态，两处更新时点不同，评估时出现“评审已通过但证据仍显示待确认”的情况。
- 模板复制导致字段口径不一致。不同项目复制同一份表格模板后各自增删字段，同一工作产品在不同项目中的证据字段名称、状态取值不同，汇总时无法直接合并，只能人工对照。
这些环节的共同特征是：同一事实被写入了两个位置，且没有约定哪一处为准。下面给出的分工规则，核心就是为每类事实指定唯一归属，并规定其他位置的获取方式。
分工规则与避免重复的维护机制
避免重复维护不靠减少表格数量，而靠明确每类信息只有一个写入点，其余位置通过引用、带出或核对获得。以下规则可以直接落到日常维护动作中。
| 信息类别 | 唯一维护点 | 其他工件的处理方式 |
|---|---|---|
| 工作产品定义（名称、类别、模板、评审与基线要求） | 工作产品清单 | 证据清单只引用条目标识；矩阵不涉及 |
| 工作产品实例状态（位置、责任人、完成与确认状态） | 证据清单 | 清单不记录项目实例；矩阵不复制状态描述 |
| 对象间追溯关系 | 双向追溯矩阵 | 清单与证据清单不维护关系，仅在需要时引用矩阵视图 |
| 评审结论 | 评审记录（作为证据的一部分） | 证据清单引用评审记录并反映状态，不重复写结论正文 |
变更时的单向更新与同步顺序
变更发生时按固定顺序处理，可以避免多处同时改动造成的冲突。以需求变更为例：先在需求对象上完成变更并更新版本；再由追溯矩阵补充或调整受影响的关系链接；随后由各下游工作产品责任人更新实例，证据清单中的状态随之变化；最后在基线节点核对清单条目覆盖是否完整。整个过程只改一处源头，其余位置通过引用关系反映变化。
工作产品清单本身的变更走另一条路径：过程定义调整后发布新版本清单，项目通过裁剪说明确认适用条目，证据清单按新条目补充或归档实例记录。清单版本与项目裁剪记录一并留存，便于评估时说明差异来源。
评审与基线节点的核对动作
在每个评审节点和基线节点设置固定的核对动作，把三者的联动变成例行检查：核对证据清单中每个必备条目是否都有对应实例且状态为已确认；核对追溯矩阵中新增或变更的需求是否都有下游实现与验证关系；核对矩阵引用的对象标识是否仍有效。核对发现的问题回到唯一维护点修正，不在核对表中直接改数据。
在工具承载方面，ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；并可贯通需求、开发、测试等关键环节，建立端到端追溯能力。将工作产品模板、评审节点和过程数据沉淀为可复用资产后，项目中的证据记录与追溯关系可以围绕同一组对象维护，减少在多个表格间手工同步。具体字段配置与追溯粒度需结合项目实际情况确定。
适配场景与选择建议
分工原则一致，落地形态可以随项目规模和评估阶段调整。以下建议按场景给出取舍方向，前提是保持唯一维护点不被打破。
小规模项目可合并哪些视图
团队规模小、工作产品类型少的项目，可以把证据清单与追溯矩阵放在同一张表的不同区域展示，或用一个视图按工作产品筛选关系。合并的是展示方式，工作产品定义仍保留在清单中，实例状态与关系仍分别维护。合并后要约定状态字段与关系字段的填写责任，避免同一行内两类信息互相覆盖。
多项目复用时的拆分方式
多个项目共用一套过程定义时，工作产品清单保持组织级唯一，项目差异通过裁剪说明表达；证据清单按项目或产品线拆分，各自维护实例；追溯矩阵按项目维护关系，跨项目复用需求时通过标识引用，不复制需求内容。这样新增项目时只需复制裁剪模板和证据表结构，不需要重建产品定义。
评估前集中核对的重点
评估准备阶段时间有限，核对应集中在三处：必备工作产品的证据覆盖率，即清单中的必备条目是否都有可定位的实例；追溯关系的双向完整性，即正向与反向是否都能走通；状态一致性，即证据状态与评审记录结论是否吻合。这三项核对通过引用和视图完成，不重新誊写数据。
工具承载与手工表格的适用条件
工作产品类型多、变更频繁、需要跨项目汇总时，用工具承载对象与关系更合适，引用和状态联动可以减少手工同步。项目数量少、评估范围固定、团队对表格操作更熟悉时，手工表格配合明确的字段规范和核对清单也能运转，但需要指定每张表的唯一维护人和更新时点。无论哪种方式，判断标准相同：同一事实是否只有一个写入点，其他位置是否只做引用。
常见问题
工作产品清单由组织统一维护，项目发现缺少某类工作产品时应该怎么处理？
项目不直接改写组织级清单条目。常见做法是先在项目裁剪说明中记录差异及理由，同时向过程工程或质量部门提出清单变更建议；清单发布新版本后，项目再按新条目补充证据记录。这样清单始终是唯一定义源，项目差异有据可查，评估时也能说明裁剪依据。
追溯矩阵里的需求标题和版本经常变，怎样减少反复修改？
矩阵中只保留上游与下游对象的唯一标识和关系类型，标题、版本、责任人等信息从被引用对象读取。需求改名或升版时只改需求对象本身，矩阵中的链接保持不变。如果当前使用手工表格，至少要把名称列改为标识列，并在核对时通过标识回查对象，避免逐格比对文字。
评审通过后，证据状态和评审记录两处都要更新吗？
评审结论以评审记录为准，证据清单只反映状态并引用该记录，不重复抄写结论正文。更新时点建议统一为评审结论确认之后，由证据清单责任人一次性更新状态。这样评估时看到的状态与评审记录一致，也不会出现两处结论措辞不同的情况。
项目数量少、暂时用表格管理，怎样保证三个工件不重新变成互相抄写？
手工表格同样可以落实单一维护点：为每张表指定唯一维护人和更新时点；证据表只保留引用清单条目的标识列，不写产品描述；矩阵只保留对象标识与关系字段。再配合评审与基线节点的固定核对动作，检查覆盖率与双向完整性。表格形态不改变分工原则，关键是同一事实只有一个写入位置。
用工具承载这三个工件时，需要重点确认哪些能力？
重点看三件事：工作产品定义能否作为独立对象被项目引用，而不是每个项目各建一份；需求、设计、测试等对象之间能否建立并查询双向关系；状态与评审结论能否围绕同一对象联动。ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯，并可贯通需求、开发、测试等关键环节建立端到端追溯。具体字段配置与追溯粒度需结合项目实际情况确定。
