检查ASPICE证据的完整性和一致性，先按过程域和评估范围确定证据清单与时间窗，再逐条核对证据的存在性、可追溯性和内容一致性，最后用抽样复核和缺陷统计给出可复算的结论。完整性看应有证据是否齐全、版本是否有效；一致性看同一事实在需求、设计、测试、评审和变更记录之间是否对得上。以下方法适用于汽车研发评估准备阶段的内部自查，也可用于整改后的复检。
要点总览（TL;DR）
- 检查ASPICE证据完整性，先按过程域、项目和时间窗固定证据清单，再全量核对每条证据的存在性与版本有效性，用缺失率和有效率两个指标量化。
- 一致性检查沿需求—设计—测试—变更的追溯链核对，再按过程域分层抽样复核内容，用不一致率记录结果，并同时报告抽查条目数。
- 指标口径要在检查前写死：分母按过程域、工作产品类型或条目三选一，分母为零的过程域标注“不适用”，不按0%或100%计入汇总。
- 证据检查结果只反映证据层面的齐全与吻合程度，不能替代正式评估结论；整改复检应沿用同一清单、同一分母和同一时间窗。
- 证据清单、追溯关联和缺陷记录可以在研发管理工具中统一承载，ONES 的工作项自定义字段、状态流转和条目关联可用于留存检查记录。
评估目标：这次证据检查要回答什么
证据检查的第一步是把“查完整性和一致性”转成一组可以回答“是/否”或“多少”的判定问题。目标说明写在一页纸上，参与检查的人按同一份说明取数，后续指标才有可比性。
评估对象需要写清楚三层：纳入哪些过程域（例如需求分析、软件设计、软件测试等，按本次评估范围列明）、覆盖哪些项目或产品线、以哪个基线或发布节点作为证据版本的时间窗。范围写得越具体，证据清单越容易收敛。
完整性与一致性对应两类不同的问题。完整性问的是“应该有的证据是否都在、版本是否有效”，典型判定问题包括：该过程域要求的每类工作产品是否都有对应记录，记录是否处于已评审或已批准状态，是否属于本次时间窗内的有效版本。一致性问的是“同一事实在不同证据之间是否对得上”，典型判定问题包括：需求条目是否都能追到设计和测试，测试用例覆盖的需求是否与需求基线一致，变更记录是否同步更新了受影响的设计与测试，评审结论与工作产品状态是否吻合。
评估结论的用途要在目标中声明，常见有三种：评估准备（判断距离正式评估还差什么）、内部自查（发现过程执行中的系统性缺口）、整改验证（确认上次发现的缺陷已关闭）。用途不同，抽样深度和缺陷分类的粒度可以不同，但指标口径应保持一致，便于前后对比。
同时写明不纳入的范围，例如控制算法设计本身、硬件设计与验证、对外认证承诺与认证结论。这些内容不属于证据检查的判定对象，写清楚可以避免检查过程中范围蔓延。
交付物是一页评估目标说明，包含：纳入的过程域与项目、时间窗与基线、完整性与一致性各自的判定问题清单、结论用途、排除范围。
指标与范围：完整性和一致性怎么量化
指标定义要写到别人拿着同样的数据能算出同样结果的程度。核心是四个要素：公式、分子分母、单位、时间窗。下表给出两个主指标及配套统计项的定义框架，具体数值按项目实际填写。
| 指标 | 公式 | 分子 | 分母 | 单位 | 时间窗口径 |
|---|---|---|---|---|---|
| 证据缺失率 | 缺失证据数 ÷ 应有证据数 | 清单中判定为缺失或失效的证据条目数 | 按过程域要求应存在的证据条目总数 | 百分比（%） | 以指定基线或发布节点为准 |
| 证据有效率 | 实有有效证据数 ÷ 应有证据数 | 存在且版本、审批状态、关联关系均符合要求的条目数 | 同上 | 百分比（%） | 同上 |
| 一致性抽查不一致率 | 不一致条目数 ÷ 抽查条目数 | 追溯链断裂、内容矛盾或版本不匹配的抽查条目数 | 实际完成复核的抽查条目数 | 百分比（%） | 抽查条目所属基线 |
| 缺陷密度（辅助） | 缺陷数 ÷ 检查条目数 | 记录在缺陷表中的问题数 | 本次检查覆盖的条目总数 | 个/百条 | 本次检查期间 |
分母口径必须在检查前固定，常见有三种选择：按过程域统计（每个过程域一个分母，适合向评估范围对齐）、按工作产品类型统计（计划类、需求类、测试类各一个分母，适合定位薄弱环节）、按条目统计（以需求条目或测试用例为分母，适合做追溯一致性分析）。三种口径的结果不能混用，同一份报告内应声明采用哪一种。
缺失率与有效率互补，两者之和在理想情况下为100%，但实际统计中会出现“存在但失效”的中间状态，因此建议同时报告缺失数、失效数和有效数三个绝对数，避免百分比掩盖分布。
分母为零的情形要预先约定处理方式。例如某过程域在本次范围内没有适用的工作产品，则该过程域不计算比率，在报告中标注“不适用”，不按0%或100%计入汇总。证据之间不可比时（例如不同项目的模板版本不同），应分组统计并在结论中说明分组依据，不做跨组直接平均。
时间窗与版本口径同样要写死：以哪个基线、哪个发布节点或哪个评审通过日期作为证据有效性的判断时点。同一证据存在多个版本时，只统计时间窗内且状态有效的版本，历史版本不计入分子也不计入分母。
数据口径与证据来源：清单从哪里来、依据什么判
证据清单是检查的取数底稿，来源应可追溯到过程域要求、项目计划和组织的模板与过程资产。清单构建时按“过程域—工作产品类型—具体条目”三级展开，每一条对应一个可核对的证据对象。
证据类型通常覆盖：项目计划与裁剪记录、需求规格与需求基线、设计与架构文档、测试计划与测试用例及测试记录、评审记录与评审结论、变更请求与变更影响分析、问题与缺陷记录。清单中为每条证据预留字段：证据编号、所属过程域、要求来源、存放位置、责任人、应有版本或状态、检查日期、检查结论。
判定依据要具体到可操作的条件，避免“看起来齐全”这类主观判断。常用判定条件包括：条目要求（该证据是否属于过程域强制要求）、模板字段（必填字段是否完整）、评审结论（是否已评审通过、遗留问题是否关闭）、版本状态（是否为受控版本、是否在时间窗内）、关联关系（是否与上下游证据建立可追溯链接）。
证据有效性建议用三个条件同时满足来判定：存在、状态有效（已评审或已批准）、关联完整（能追到上游来源和下游使用）。只满足“存在”的条目计入实有数但不计入有效数，这样有效率指标才能反映真实可用程度。
取数过程要留痕：每条证据记录检查人、检查日期和判定理由，争议条目单独标记。留痕的作用是复检时能按同一口径重算，也便于不同检查人之间交叉核对。
在研发管理工具中承载这套清单时，可以把证据条目建成工作项或文档条目，用状态字段表达“存在/有效/失效”，用关联关系表达追溯链，缺陷记录单独建表并回链到证据条目。ONES 支持工作项自定义字段、状态流转和条目间关联，检查记录与缺陷可以在同一套数据里留存，复检时按相同字段重新取数即可。工具承载的是清单与记录的管理动作，判定标准仍由评估目标说明和判定依据决定。
检查步骤：从清单核对到抽样复核
检查按“先全量、后抽样、再复核”的顺序推进，每一步都有明确的输入、动作和输出。
第一步，全量存在性核对。按证据清单逐条确认证据是否存在、版本是否在时间窗内、状态是否有效。输出是每条证据的判定结果（有效、失效、缺失）和对应的绝对数。这一步不做内容判断，只做存在与状态核对，速度快、覆盖全。
第二步，追溯链核对。沿需求—设计—测试—变更的主链逐条检查关联关系：每条需求是否有对应的设计条目和测试用例，测试用例是否回链到需求，变更请求是否标注了受影响的需求、设计和测试并完成同步更新。追溯链断裂的条目直接记为不一致候选。
第三步，分层抽样做内容一致性复核。抽样按过程域和证据类型分层，保证每个过程域都有样本；样本量根据评估用途确定，内部自查可适度减少，评估准备阶段应覆盖主要过程域和关键工作产品。复核内容是同一事实在不同证据中的表述是否一致，例如需求描述与测试用例的预期结果是否对应、设计文档的接口定义与测试环境配置是否吻合、评审结论中的整改项是否在后续版本中落实。
第四步，记录缺陷并分类。缺陷分为三类：缺失（应有未有）、失效（存在但版本或状态不符合要求）、不一致（追溯断裂或内容矛盾）。每条缺陷记录证据编号、缺陷类型、影响的过程域、发现依据和责任人。
第五步，争议条目二次复核。对判定有分歧的条目，由另一名检查人按同一判定依据独立复核，复核结论和理由一并留痕。二次复核的作用是减少单人判断偏差，也让最终结论经得起追问。
五步完成后输出两份交付物：检查步骤流程说明（供复检复用）和缺陷记录表（含分类统计）。
算例：一个过程域的完整性与一致性计算
以下为演示情景，数据为假设值，用于说明公式代入方式，不代表任何真实项目水平。
设定：某项目软件需求分析过程域纳入本次检查，时间窗为某基线版本，证据清单按工作产品类型列出应有证据40条，其中需求规格、需求评审记录、需求变更记录、需求追溯矩阵四类各10条。
完整性计算：全量核对后，实有证据36条，其中状态有效且关联完整的34条，失效2条，缺失4条。则应有证据数40，实有有效证据数34，缺失率 =（4+2）÷ 40 = 15%，有效率 = 34 ÷ 40 = 85%。报告中同时列出缺失4条、失效2条、有效34条三个绝对数。
一致性计算：从34条有效证据关联的需求条目中分层抽取20条做追溯与内容复核，发现3条追溯链断裂（测试用例未回链需求）、1条内容矛盾（需求描述与测试预期结果不一致），一致条目16条。则抽查条目数20，一致条目数16，不一致率 = 4 ÷ 20 = 20%。
分母为零的处理示例：假设同一检查中某过程域在本次范围内没有适用的变更记录（项目处于初始基线，尚未发生变更），则该过程域的变更类证据分母为0，标注“不适用”，不计算比率，也不并入总体缺失率的分母。
结论写法示例：“软件需求分析过程域在指定基线时间窗内，证据有效率85%（34/40），缺失率15%（6/40，其中缺失4条、失效2条）；一致性抽查不一致率20%（4/20），缺陷集中在追溯链断裂。建议优先补齐缺失的需求评审记录，并修复测试用例与需求的关联。”结论中给出数值、分子分母和主要缺陷分布，便于复算和跟踪整改。
解读与限制：结果能说明什么、不能说明什么
证据检查结果反映的是证据层面的齐全程度和相互吻合程度，解读时需要守住几条边界。
高完整率不等于过程执行到位。证据齐全可能来自事后补文档，也可能来自模板填写规范但内容空泛。完整性指标回答“有没有、是否有效”，过程执行质量需要结合评审记录的实际内容、缺陷趋势和访谈判断，单看完整率会高估过程成熟度。
抽样一致率受样本量和抽样方式影响。样本量小、抽样集中在容易核对的条目时，一致率会偏高；分层抽样覆盖主要过程域时结果更稳健，但仍存在抽样误差。报告一致率时应同时给出抽查条目数和抽样方法，避免只报百分比。
不同项目、不同过程域的结果不可直接横向比较。证据要求、模板版本、项目阶段不同，分母构成就不同。跨项目对比应限定在相同过程域、相同口径和相近时间窗内，否则比较没有意义。
证据检查结论与正式评估结论是两件事。内部检查给出的是自查发现和整改输入，正式评估由具备资质的评估师按评估模型执行，两者在抽样规则、评级方法和结论效力上都不同。自查结果好，不能替代正式评估，也不构成任何认证承诺。
整改后复检要保持口径一致：沿用同一份证据清单、同一分母定义、同一时间窗规则和同一缺陷分类，才能判断整改是否真正收敛。口径变了，前后数据不可比，复检结论也就失去参考价值。
常见问题
检查ASPICE证据时，证据清单应该由谁维护、多久更新一次？
清单通常由过程改进或质量角色牵头维护，各过程域的责任人参与确认条目。更新时机建议绑定三个节点：评估范围确定时建立初始清单，项目基线或发布节点变更时同步调整时间窗和应有证据，每次检查结束后根据缺陷分布补充遗漏条目。清单本身应纳入版本管理，保留每次变更记录，这样复检时能说明口径是否发生变化。
如果不同检查人对同一条证据的判定不一致，怎么处理？
先回到判定依据上找分歧点：是条目要求理解不同、模板字段是否必填有争议，还是版本状态判断标准不一致。判定依据能澄清的，按依据统一；依据本身表述模糊的，应在评估目标说明中补充判定条件，再对争议条目重新判定。无法当场统一的，由第二名检查人独立复核并留痕，复核结论作为最终结果。分歧条目集中出现，往往说明判定依据需要细化，而不是检查人执行有问题。
项目处于早期阶段，很多过程域还没有产生变更记录，缺失率会不会被算高？
不会，前提是分母口径提前约定。某过程域在本次范围内没有适用的工作产品时，该过程域标注“不适用”，不计算比率，也不并入总体缺失率的分母。需要区分的是“不适用”和“应有但缺失”：如果项目计划中明确该阶段应产生变更记录而实际没有，就属于缺失，应计入分子。判断依据是项目计划和过程域要求，而不是当前有没有文件。
内部自查的一致率很高，是否说明已经具备正式评估条件？
不能直接这样推断。自查一致率高说明抽样条目在追溯和内容上对得上，但正式评估由具备资质的评估师按评估模型执行，抽样规则、评级方法和结论效力都不同。自查结果可以作为评估准备的输入，用来定位整改重点，但不能替代正式评估，也不构成任何认证承诺。建议在自查基础上补充过程执行质量的证据，例如评审记录的实际内容和缺陷趋势。
整改完成后复检，指标口径需要重新设计吗？
不需要重新设计，应沿用同一份证据清单、同一分母定义、同一时间窗规则和同一缺陷分类。口径一致，前后数据才可比，才能判断整改是否真正收敛。如果评估范围发生变化，例如新增了过程域，应在报告中单独说明新增部分，不与原口径数据直接合并计算。复检时还要核对清单版本，确认期间没有未经记录的条目调整。
