交付物完整性检查要回答的是：一个交付批次里，清单上该交的资产是否交齐、交得对不对、证据能否核验。做法是先冻结应交付清单与版本快照，再以“通过校验的已交付条目数÷应交付条目数”计算完整性率，并用缺项清单、证据状态和复核记录解释结果。本文给出指标口径、通过标准、计算步骤和一个可复算的例子，适用于研发交付评审与验收场景。
要点总览（TL;DR）
- 完整性率＝通过校验的已交付条目数÷应交付条目数×100%，统计前先冻结应交付清单与版本快照，明确统计截止时点。
- 每类交付物预先定义通过标准与所需证据，条目按通过、未提交、已提交未校验、豁免四类分别计数，豁免项单列不并入通过。
- 按需求文档、设计说明、测试报告、发布说明、验收记录等类别分层统计，避免文档数量掩盖关键缺项。
- 示例批次20项应交付、16项通过，完整性率80.0%；豁免项剔除口径下为84.2%，同一报告期内口径需保持一致。
- 完整性率只反映交付齐备程度，不直接代表质量或项目成功；不设通用达标线，阈值结合项目类型与合同或流程要求确定。
检查目标：完整性要回答哪几个问题
交付物完整性检查围绕三类问题展开。第一类是“该交的是否交齐”，即对照应交付清单逐项确认是否存在；第二类是“交的对不对”，即提交的内容是否属于本次交付批次、版本是否与基线一致、格式与要素是否满足约定；第三类是“证据是否可核”，即评审记录、签署状态、附件版本号等能否支撑“已通过”的判断。三类问题分别对应数量、版本和证据，缺一类都会让结论站不住。
评估对象是可交付资产本体，常见条目包括需求文档、设计说明、测试报告、发布说明和验收记录。检查以条目为单位，关注条目是否存在、版本是否正确、证据是否齐全，不评价文档写作水平，也不替代技术评审。组织级配置基线的建立与维护属于研发配置与基线管理的工作，制品仓库的底层开发与构建流水线实现属于制品管理范畴，本文只在需要引用清单和版本快照时与其衔接，不展开其内部机制。
明确边界还有一个实际作用：让完整性检查的结论可以被复算。只要清单、版本快照和通过标准固定，不同人按同一口径取数应得到相同结果。反之，如果检查过程中清单被临时增补、版本口径反复调整，比率就失去可比性。
指标与范围：完整性率怎么定义
完整性率的计算公式为：完整性率＝通过校验的已交付条目数÷应交付条目数×100%，单位为百分比。分母是某一交付批次或某一统计时间窗内，按应交付清单应当交付的条目总数；分子是其中已提交且通过校验的条目数。“已提交”指条目已进入交付记录并关联到本批次，“通过校验”指满足该类交付物预先定义的通过标准。只提交未校验的条目计入分母，不计入分子。
统计前需要固定两个口径。一是时间窗，明确统计截止时点，例如“截至交付评审日前一个工作日”，避免评审当天仍在补交导致分子持续变化。二是版本快照，以冻结时刻的清单和条目版本为准，后续变更单独记录为变更项，不回溯修改已发布的统计结果。分母与分子必须来自同一份冻结清单，否则比率不可复算。
统计应按交付物类别分层。仅看总数时，数量多的文档类条目可能掩盖关键缺项，例如测试报告只有一份但缺失，对总数的拉低有限，对交付风险的影响却很大。分层后可以同时看到总体完整性和关键类别完整性。
| 口径要素 | 定义 | 注意事项 |
|---|---|---|
| 分母 | 冻结清单中本批次应交付条目数 | 含未提交、已提交未校验、豁免条目，是否剔除豁免需在口径中写明 |
| 分子 | 已提交且通过校验的条目数 | 仅提交未校验不计入 |
| 时间窗 | 明确的统计截止时点 | 同一批次多次统计需注明各自时点 |
| 版本快照 | 冻结时刻的清单与条目版本 | 后续变更单独记录，不回溯修改 |
| 分层维度 | 按交付物类别统计 | 至少区分文档类、测试类、发布与验收类 |
| 单位 | 百分比，保留一位小数 | 同时报告分子分母原始数，便于复算 |
数据口径与证据：每条交付物怎么判定通过
通过标准需要按类别预先定义，并在检查开始前与交付方确认。标准的作用是把“交了什么”转化为“是否合格”，使判定不依赖检查人的主观印象。每类交付物至少应写明判定条件、所需证据和证据的存放位置。
| 交付物类别 | 通过标准示例 | 所需证据 | 数据来源 |
|---|---|---|---|
| 需求文档 | 覆盖本批次范围，已完成评审并形成结论 | 评审记录、评审结论、文档版本号 | 交付清单、评审记录、关联工作项状态 |
| 设计说明 | 与需求条目对应，关键设计决策有记录 | 评审签署状态、附件版本号 | 交付清单、评审记录 |
| 测试报告 | 含测试范围、执行结果、缺陷统计与明确结论 | 报告结论页、签署或审批状态 | 交付清单、测试工作项状态 |
| 发布说明 | 含版本内容、部署步骤与回滚方案 | 发布审批记录、版本号 | 交付清单、发布工作项状态 |
| 验收记录 | 验收项与清单一致，结论明确并有确认人 | 验收签署、确认时间 | 交付清单、验收记录 |
条目状态应分为四类分别计数：通过、未提交、已提交未校验、豁免。前三类构成分母的主体，豁免项是否计入分母需在口径中事先写明，并在报告中单列，不能悄悄并入通过。缺失值按“未提交”处理并标注原因，例如责任人未响应或依赖外部输入，避免把数据缺失误读为不合格。
数据来源应可追溯到具体条目。交付清单提供应交付范围，工作项状态提供提交与流转信息，评审记录提供通过证据。三者通过条目编号或工作项标识关联，任何一条汇总数字都应能下钻到原始记录。若某类交付物的证据只存在于线下，需在清单中登记证据位置和登记人，保证复核时可查。
计算与评估步骤：从清单到结论的流程
完整性检查按五个步骤执行，每一步都有明确产物，便于交接和复核。
- 冻结应交付清单与版本快照。由交付负责人确认本批次范围，列出全部应交付条目及类别，记录冻结时间。产物是带版本号的清单，后续变更以变更单形式追加。
- 逐条采集提交状态与证据。检查人按清单逐条核对是否存在、版本是否匹配，并登记证据位置。产物是条目状态明细表，每条包含状态、证据链接或位置、采集时间。
- 按通过标准判定并分类标记。对照预先定义的通过标准，将每条标记为通过、未提交、已提交未校验或豁免，未通过项写明原因。产物是带判定结果的明细表。
- 汇总分层完整性率并输出缺项清单。按类别和总体分别计算比率，列出全部未通过条目及其责任人和影响。产物是完整性报告与缺项清单。
- 由责任人复核并记录结论。交付负责人对缺项清单逐项确认，能补交的约定补交时间，确认豁免的登记理由，最后形成本次检查结论并归档。产物是复核记录与结论页。
角色分工上，交付负责人对清单完整性和豁免判定负责，检查人负责取数与判定执行，条目责任人负责补交和提供证据，评审或质量角色对结论进行确认。复核环节不可省略，因为比率本身无法说明缺项是否可接受，只有责任人确认后的缺项清单才能支撑后续决策。
当团队在系统中管理交付清单、工作项状态和评审记录时，上述取数可以依托统一的工作项与文档记录完成。ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯，并可将交付物模板、评审节点沉淀为可复用资产；ONES Performance 则对系统内流转的研发数据做多维度分析。完整性率的公式与通过标准仍需团队自行定义，系统承载的是清单、状态与证据的记录和追溯。
例子：一个交付批次的完整性计算
以下为演示情景，数字为说明计算方式而设，非真实项目数据。某交付批次冻结清单共20项应交付条目，检查截止时点状态如下：通过校验16项，未提交2项，已提交未校验1项，豁免1项。
| 状态 | 条目数 | 是否计入分母 | 是否计入分子 |
|---|---|---|---|
| 通过校验 | 16 | 是 | 是 |
| 未提交 | 2 | 是 | 否 |
| 已提交未校验 | 1 | 是 | 否 |
| 豁免 | 1 | 按口径，本例计入分母 | 否 |
| 合计 | 20 | 20 | 16 |
按本例口径，完整性率＝16÷20×100%＝80.0%。若组织约定豁免项从分母剔除，则分母为19，完整性率为16÷19×100%≈84.2%。两种口径都能用，关键是同一批次、同一报告期内保持一致，并在报告中注明所用口径。豁免项单列展示，不并入通过数。
缺项清单示例：条目D-07测试报告未提交，责任人张某，影响本批次测试结论无法归档；条目D-12发布说明已提交未校验，责任人李某，缺少回滚方案章节；条目D-15设计说明未提交，责任人王某，依赖上游接口文档。豁免项D-19为外部合规材料，因合同约定由客户方提供，登记豁免理由与确认人。
分母为零的情形单独说明：若某批次经确认没有任何应交付条目，例如纯内部技术预研且不产生对外交付物，报告应写“本批次无应交付条目”，不输出0%或100%。输出0%会被误读为全部缺失，输出100%会被误读为全部合格，两者都不符合事实。
解读与限制：比率之外还要看什么
完整性率反映交付齐备程度，不直接代表交付物质量，也不代表项目成功。一份测试报告按时提交且证据齐全，只能说明它通过了完整性校验，报告结论是否可靠仍需技术评审判断。把完整性率当作质量结论，容易掩盖内容层面的问题。
比较需要在同口径下进行。不同批次如果清单范围、豁免规则、时间窗或类别构成不同，比率之间不具备直接可比性。跨团队比较前应先对齐口径，必要时按类别分别比较，而不是只比总数。同一批次在不同时点的统计结果也应注明时点，避免把补交后的数字与评审前的数字混用。
清单本身的质量决定指标的可信度。如果应交付清单遗漏了关键条目，比率会虚高，且这种偏差不会在计算中暴露。因此需要定期校验清单来源，例如对照流程模板、合同交付条款或阶段评审要求检查清单是否覆盖完整，并把清单变更纳入版本管理。
本文不设通用达标线。阈值应结合项目类型、合同约定或组织流程要求确定，例如对外交付项目可能要求关键类别全部通过，内部迭代项目可采用分层阈值。无论采用何种阈值，都应同时查看缺项清单、豁免记录和复核结论，用多项信息共同支撑交付评审决策。
常见问题
应交付清单在统计过程中被临时增补，完整性率还能用吗？
可以继续统计，但需要把增补部分作为变更项单独记录，并注明变更时间和确认人。已发布的统计结果以冻结时刻的清单为准，不回溯修改；下一次统计使用更新后的清单版本，并在报告中说明两版清单的差异。这样同一批次不同时点的数字才不会被混用。
豁免项到底该不该计入分母？
两种口径都可行，关键是事先写明并在同一批次、同一报告期内保持一致。计入分母时，豁免项会拉低完整性率，但能体现“清单上原本要求交付”的事实；从分母剔除时，比率更聚焦于实际可交付范围。无论采用哪种，豁免项都应在报告中单列，附豁免理由和确认人，不能并入通过数。
关键类别只有一两个条目，比率波动很大，怎么解读？
条目基数小的类别，单条状态变化就会带来较大百分比波动，此时百分比本身的信息量有限。建议同时报告分子分母原始数，并以缺项清单为主进行判断，例如“测试报告1项未提交”比“该类完整性率0%”更直接。跨批次比较时也应按类别分别看原始条目数，避免只比百分比。
交付物只存在于线下，证据怎么登记才能复核？
在清单中为每条线下交付物登记证据位置、登记人和登记时间，例如纸质签署件的归档编号或扫描件存放路径。复核时按登记信息逐条查证，判定结果与证据位置一并写入明细表。线下证据同样需要版本信息，避免用旧版本签署件支撑本次交付。
用系统承载交付清单和评审记录时，完整性率能自动算出来吗？
公式与通过标准仍需团队自行定义，系统承载的是清单、状态与证据的记录和追溯。在 ONES 中，交付清单、工作项状态和评审记录可以依托统一的工作项与文档记录管理，ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；ONES Performance 可对系统内流转的研发数据做多维度分析。是否提供现成的完整性率指标或报表模板，需以实际开通模块为准。
