ASPICE研发过程管理要解决的是“过程可执行、结果可追溯、证据可核查”。比较稳妥的推进顺序是：先按项目等级和客户要求划定过程域与项目范围，再把过程要求拆成日常活动和对应工作产品，明确每项活动的负责人、评审人和证据归属，让记录随研发活动同步产生，最后用内部评估和差距整改形成闭环。下面按这五个环节展开，并给出可直接套用的表格与检查清单。
要点总览（TL;DR）
- 先按项目等级目标和客户合同要求划定过程域与项目范围，形成有确认人签字的范围清单，再进入活动拆解。
- 把每个过程域拆成有输入、动作、输出和可核验完成标志的活动，配套工作产品模板，汇总为过程活动与工作产品对照表。
- 每项活动设唯一执行责任人，评审责任与执行责任分离，并在职责矩阵中写明证据留存责任。
- 将工作产品产出时点绑定到研发工作项状态流转，需求、设计、实现、测试、变更记录随活动同步产生，阶段评审时检查追溯链完整性。
- 用分批内部评估记录并分级差距，整改针对根因，复查以运行记录证明改进生效，最后按完成检查清单判断过程是否可运行。
先定范围：哪些过程域和项目要纳入管理
ASPICE研发过程管理的第一步是划定边界。范围不清，后续的活动拆解、角色分工和证据准备都会失焦，评估时也容易出现“该管的没管、管了的没证据”。范围确定要同时回答三个问题：管哪些过程域、管哪些项目、管到哪一层组织。
过程域范围通常由两个因素决定。一是项目所对应的能力等级目标，等级越高，覆盖的过程域越多、过程要求的深度也越高；二是客户或主机厂的合同要求，部分项目会指定必须覆盖的过程域和评估方式。团队应先取得这两项输入，再对照ASPICE过程参考模型列出候选清单，逐项标注“纳入/暂不纳入”及理由，避免凭经验拍板。
项目范围要明确到具体项目、团队和阶段。同一组织内不同项目的成熟度、交付节奏差异较大，建议优先选择有客户评估要求或交付风险较高的项目作为首批纳入对象，其余项目按批次推进。范围清单中应写明项目名称、涉及的产品线、纳入的过程域、对应的责任人以及计划启动时间。
范围清单形成后需要一次正式确认。确认人通常是研发负责人和质量负责人，确认内容包括过程域取舍理由、项目优先级和资源投入。确认记录本身也应作为过程管理的第一份证据留存。
| 范围要素 | 需要写清的内容 | 常见遗漏 |
|---|---|---|
| 过程域 | 纳入的过程域名称、对应等级目标、取舍理由 | 只写“按ASPICE执行”，未列具体过程域 |
| 项目 | 项目名称、产品线、当前阶段、纳入批次 | 范围覆盖到部门而非具体项目 |
| 组织边界 | 涉及的团队、供应商协作接口 | 忽略外包或供应商交付部分的证据要求 |
| 责任人 | 范围清单确认人、各过程域负责人 | 只有质量部门签字，研发侧无确认 |
把过程域拆成可执行的活动与工作产品
范围确定后，下一步是把过程域的条款语言翻译成团队每天能执行的动作。拆解的基本单位是“活动”：一项活动应有明确的触发条件、输入、执行动作、输出工作产品和完成标志。拆得太粗会变成口号，拆得太细会增加无谓的记录负担，建议以“一个角色在一次工作节奏内能完成并留下记录”为粒度。
拆解可以按以下顺序进行：先列出该过程域要求的工作产品，再倒推产生这些工作产品的活动，然后为每项活动补充输入和前置条件，最后定义完成标志。完成标志要写成可核验的状态，例如“需求评审记录已归档且评审意见全部关闭”，而不是“需求已评审”。
工作产品清单需要配套模板。模板不必复杂，但要包含必填字段、版本信息和审批栏，确保不同项目产出的记录结构一致，便于评估时抽样检查。模板应与活动清单一一对应，避免出现“有模板但没人用”或“有活动但无固定格式”的情况。
| 拆解要素 | 写法示例 | 完成标志示例 |
|---|---|---|
| 活动 | 需求评审 | 评审记录归档，意见关闭率100% |
| 输入 | 需求规格草案、评审检查表 | 输入版本号已登记 |
| 输出工作产品 | 评审记录、修订后的需求规格 | 工作产品状态为“已批准” |
| 责任人 | 需求负责人组织，系统负责人评审 | 评审人与被评审人已签署 |
拆解结果汇总为“过程活动与工作产品对照表”，按过程域分组，逐行列出活动、输入、输出、责任角色和完成标志。这张表是后续角色分工和证据检查的基础，应随过程改进持续更新。
角色与职责：谁负责、谁评审、谁留证据
活动清单只有落到人头上才能运行。ASPICE研发过程管理中的角色通常包括项目经理、需求负责人、设计负责人、开发负责人、测试负责人、质量负责人和配置管理员，具体设置可按团队规模调整，但每项活动必须有唯一的执行责任人和明确的评审人。
职责划分要区分三类责任：执行责任，即谁完成活动并产出工作产品；评审责任，即谁检查工作产品的充分性和正确性；留存责任，即谁确保记录归档到正确位置并保持可查。三类责任可以由同一人承担部分工作，但评审责任应与执行责任分离，否则评审记录难以体现独立性。
评审与审批职责需要单独定义。技术评审关注内容正确性，管理审批关注是否允许进入下一阶段，两者不能互相替代。建议在职责矩阵中标注每项工作产品的评审级别和审批人，避免所有文档都走同一套签字流程，造成形式化。
| 角色 | 主要活动 | 关键工作产品 | 证据留存责任 |
|---|---|---|---|
| 项目经理 | 计划制定、进度跟踪、变更协调 | 项目计划、变更记录、状态报告 | 计划与变更记录归档 |
| 需求负责人 | 需求分析、需求评审组织 | 需求规格、评审记录 | 需求版本与评审意见关闭记录 |
| 设计负责人 | 架构与详细设计、设计评审 | 设计文档、设计评审记录 | 设计与需求的对应关系记录 |
| 测试负责人 | 测试计划、用例设计、测试执行 | 测试计划、用例、测试报告 | 测试结果与缺陷关联记录 |
| 质量负责人 | 过程符合性检查、内部评估组织 | 检查记录、评估报告、整改跟踪表 | 评估与整改证据归档 |
| 配置管理员 | 版本管理、基线建立 | 配置项清单、基线记录 | 版本与基线变更记录 |
职责矩阵完成后，应在项目启动会上向全体成员宣贯，并纳入新成员入职材料。矩阵不是一次性文件，人员调整或过程域扩展时需要同步更新，更新记录同样属于过程证据。
让工作产品随研发活动同步产生
证据事后补写是ASPICE推行中最常见的问题，根源往往在于产出时点没有和研发节奏绑定。可行的做法是把每项工作产品的产出时点写入活动定义，并与研发工作项的状态流转挂钩：活动开始时创建记录，活动完成时记录达到“已评审”或“已批准”状态，状态变化即形成时间戳证据。
需求、设计、实现、测试、变更各环节的产出时点可以这样安排：需求评审通过后立即归档评审记录和需求基线；设计完成后同步更新设计与需求的对应关系；代码提交与工作项关联，实现记录随提交产生；测试执行时逐条记录用例结果并关联缺陷；变更提出时同步更新受影响的需求、设计和测试用例，并保留变更前后版本。
变更与问题记录要同步维护。变更请求、影响分析、审批结论和关闭状态应形成完整链条，问题记录则要关联到发现阶段、责任人和解决验证结果。这两类记录如果只在会议纪要中体现，评估时很难证明过程受控。
双向追溯的维护动作应嵌入日常操作：需求创建时分配唯一标识，设计、实现、测试环节引用该标识，变更时沿追溯链更新受影响项。追溯关系不需要每次人工整理，但需要在阶段评审和基线建立时做一次完整性检查，确认没有孤立的需求、设计或测试用例。
在工具层面，ONES面向ASPICE研发管理的方案将项目管理、知识库、工单管理、测试管理、效能管理等模块组合使用，其线上化建设阶段定位为支持研发全生命周期流程活动和跨域协作的可追溯性。团队可以把活动清单、工作产品模板和状态流转配置到这类平台中，使记录随工作项状态变化自然沉淀；具体的追溯粒度和模块配置方式需在实施时结合项目实际确认。
示例：一个需求从提出到验证的过程记录
以下示例演示一条需求在过程管理下的完整记录链，用于说明活动、角色与证据如何对应。示例为演示情景，团队可按自身过程域裁剪。
需求提出与评审。系统负责人提出需求并登记唯一标识，需求负责人编写需求规格草案，组织需求评审。评审记录中写明参与角色、评审意见和关闭情况，评审通过后建立需求基线。此时形成的证据包括需求规格、评审记录和基线记录。
设计与实现对应记录。设计负责人依据需求编写设计说明，在文档中标注对应的需求标识；开发负责人按设计拆分开发任务，代码提交时关联任务和需求标识。设计与需求的对应关系、代码与任务的关联记录在此阶段产生。
测试验证与结果记录。测试负责人依据需求编写测试用例，用例中引用需求标识；测试执行时逐条记录结果，发现的问题登记为缺陷并关联用例和需求。测试报告汇总通过率、遗留缺陷和处理结论。
追溯关系与变更处理。阶段评审时检查需求、设计、用例、缺陷之间的追溯链是否完整。若需求发生变更，变更请求中记录影响分析，同步更新设计、用例和测试结果，并保留变更前后的版本对照。变更关闭后，追溯链重新校验一次。
| 环节 | 主要活动 | 责任角色 | 形成证据 |
|---|---|---|---|
| 需求提出 | 需求登记、规格编写 | 系统负责人、需求负责人 | 需求规格、需求标识 |
| 需求评审 | 组织评审、意见关闭 | 需求负责人、评审人 | 评审记录、需求基线 |
| 设计实现 | 设计编写、任务拆分、代码提交 | 设计负责人、开发负责人 | 设计文档、任务与提交关联记录 |
| 测试验证 | 用例设计、执行、缺陷登记 | 测试负责人 | 测试用例、测试报告、缺陷记录 |
| 变更处理 | 影响分析、同步更新、关闭 | 项目经理、各负责人 | 变更请求、版本对照记录 |
内部评估与差距整改
过程建立起来后，需要用内部评估检验其实际运行情况。内部评估的组织方式可以按过程域分批进行，由质量负责人牵头，抽调未直接参与被评估项目的成员担任评估员，减少自评自检带来的盲区。评估前明确评估范围、抽样项目和检查依据，评估中对照活动清单逐项核查工作产品是否存在、内容是否充分、状态是否及时。
差距记录要具体到可整改的程度。每条差距应写明所在过程域、涉及活动、发现的问题、证据位置和影响程度。差距可按严重程度分级：影响过程目标达成或客户评估的列为高优先级，记录不完整但过程已执行的列为中优先级，格式类问题列为低优先级。分级的作用是分配整改资源，而不是降低要求。
整改责任要落到具体角色，并设定完成时限。整改措施应针对根因，例如证据缺失如果源于产出时点未绑定活动，整改就应调整活动定义和状态流转规则，而不是要求补写文档。整改完成后由评估员复查，复查通过的条件是原差距关闭且有运行记录证明改进已生效，例如连续一个迭代按新规则产出证据。
| 字段 | 填写要求 |
|---|---|
| 差距编号 | 唯一标识，便于跟踪 |
| 过程域与活动 | 定位到具体活动 |
| 问题描述 | 写清缺失或不符合的事实 |
| 严重等级 | 高/中/低，附分级理由 |
| 整改责任人 | 具体角色姓名 |
| 整改措施与时限 | 针对根因的措施和完成日期 |
| 复查结论 | 关闭/延期，附复查证据 |
完成检查：这套过程管理是否可运行
以下检查清单用于判断过程管理是否具备可运行和可评估的基础。建议在内部评估前逐项核对，未通过项作为整改输入。
- 范围清单已确认：纳入的过程域、项目和责任人明确，取舍理由有记录。
- 活动与工作产品对照表完整：每项活动有输入、输出和可核验的完成标志。
- 工作产品模板可用：模板字段覆盖必填信息，且与活动清单一一对应。
- 角色职责已落实：每项活动有唯一执行责任人，评审责任与执行责任分离。
- 证据随活动产生：抽查近期工作产品，状态时间戳与活动完成时间一致，无集中补写痕迹。
- 变更与问题记录完整：变更请求包含影响分析和审批结论，问题记录关联到验证结果。
- 追溯关系可查：随机抽取需求，能沿设计、实现、测试、缺陷找到完整链路。
- 内部评估已执行：评估范围、抽样和结论有记录，差距完成分级。
- 整改闭环：高优先级差距已关闭或有明确时限，复查有运行记录支撑。
- 过程文件保持更新：角色调整或过程域扩展后，职责矩阵和活动清单同步修订。
这套检查通过后，过程管理具备了接受外部评估的基本条件。需要说明的是，ONES方案页面提到其满足ASPICE评估标准要求，属于方案定位表述，具体评估范围、等级和结论仍需以实际评估安排为准。过程管理的价值最终体现在日常研发中：活动有人做、产出有记录、问题可追溯、差距能关闭，评估只是对这一状态的检验。
常见问题
项目刚开始推行ASPICE，过程域范围可以一次全部纳入吗？
可以按批次推进，不必一次覆盖全部过程域。首批范围建议优先纳入客户合同明确要求、或与当前交付风险直接相关的过程域，其余过程域标注“暂不纳入”及理由，在范围清单中保留记录。批次划分的依据应写清楚，例如项目所处阶段、团队成熟度和评估时间安排。范围清单确认后如需调整，同样要走确认流程并留存变更记录，避免范围在推行过程中悄悄扩大或收缩。
团队规模较小、角色由一人兼任多项时，评审独立性怎么保证？
小团队中执行与评审由不同人承担往往有困难，可行的做法是至少保证技术评审环节有执行人以外的人员参与，例如由系统负责人或质量负责人评审需求与设计文档，并在评审记录中写明参与人和意见关闭情况。管理审批可以与技术评审合并流程，但审批结论要单独记录。若确实无法完全分离，应在职责矩阵中注明兼任情况和补偿措施，并在内部评估时重点抽查这类活动的记录质量。
工作产品已经事后补写过一轮，如何避免再次发生？
先定位补写的根因。常见原因是活动定义中没有写产出时点，或工作产品状态与研发工作项状态没有绑定。整改时应调整活动定义和状态流转规则，让记录在活动开始时创建、完成时达到已评审或已批准状态，而不是追加一次补文档的要求。可以用一个迭代做试点，抽查工作产品的状态时间戳是否与活动完成时间一致，确认规则生效后再推广到其他过程域。
内部评估发现差距后，什么条件下才算整改关闭？
关闭条件应包含两项：原差距描述的问题已消除，且有运行记录证明改进在实际项目中生效。例如证据缺失类差距，整改后需连续一个迭代按新规则产出记录，并由评估员复查确认。仅提交一份整改说明或修订后的模板，不足以关闭高优先级差距。复查结论要写入整改跟踪表，延期项注明新的完成时限和责任人。
用研发管理平台承载过程活动时，需要重点确认哪些配置？
建议在实施前确认三件事：过程活动与工作产品在平台中的承载方式，需求、设计、测试、缺陷之间的追溯链能覆盖到哪一层，以及工作产品状态变化是否留下可核查的时间记录。ONES面向ASPICE研发管理的方案将项目管理、知识库、工单管理、测试管理、效能管理等模块组合使用，其线上化建设阶段定位为支持研发全生命周期流程活动和跨域协作的可追溯性。具体追溯粒度和模块配置方式需结合项目实际在实施时确认。
