S1000D 变更管理与配置管理怎么做？版本状态和影响分析
S1000D 项目中的一次变更，可能同时影响数据模块、出版物目录、媒体、适用性、业务规则和交付包。配置管理把这些对象及其关系固定在可追溯的基线上；变更管理则负责评估、审批、实施和验证，使每次发布都能说明“改了什么、为什么改、影响了什么、谁批准了”。
变更与配置管理分别管什么？
配置管理回答“当前受控对象是什么、处于哪个版本和状态、与哪些对象有关、哪一个组合可以发布”。它关注对象识别、版本、基线、关系、状态和记录。变更管理回答“为什么要改、谁提出、谁评估、谁批准、如何实施和如何证明改对了”。二者应连接起来：变更单引用配置对象，配置基线记录已批准的变更。
| 受控对象 | 配置管理关注点 | 变更管理关注点 |
|---|---|---|
| 数据模块与文本 | 标识、版本、状态、语言、作者/审核关系、直接引用。 | 修改原因、技术审查、影响出版物和回归范围。 |
| 出版物模块与目录 | 章节、任务、DM 引用、排序和适用性关系。 | 目录增删、引用替换、读者路径和交付范围变化。 |
| 图形与媒体 | 媒体标识、版本、格式、热点、引用和授权。 | 替换、重采样、热点变化、清晰度和相关模块复核。 |
| BREX、代码表与规则 | 规则集、适用性模型、代码定义和生效基线。 | 规则变化的影响分析、兼容性、重新校验和审批。 |
| 工具与配置 | 编辑器、CSDB、校验器、转换器、模板和运行环境。 | 补丁/升级评估、试运行、回退和输出差异确认。 |
| 交付物 | 发布编号、文件清单、哈希、目标环境和有效范围。 | 修订说明、通知、替换/撤回、现场确认和归档。 |
如何建立配置基线？
基线是经过批准、可被引用和复现的一组对象及其关系。它不只是某个文件夹的副本，还应包含生成该交付物所需的规则、工具、配置和目标环境说明。基线的粒度可以按项目定义，但必须能定位到受控对象和版本。
- 识别对象：列出数据模块、出版物模块、媒体、附件、BREX/代码表、适用性配置、工具和交付组件。
- 分配标识：为对象建立稳定的标识、版本或修订记录；不要用文件路径或人工备注充当唯一身份。
- 记录关系：记录出版物到 DM、模块到媒体、适用性到配置、规则到校验任务和输出到源对象的关系。
- 定义状态：明确哪些状态可编辑、可审核、可引用、可发布和可废止，并规定状态变更责任人。
- 冻结并批准：在里程碑或发布前生成清单、哈希和工具配置快照，由责任人批准形成基线。
- 维护基线：后续变化通过变更流程进入，不直接覆盖已批准基线；必要时建立新基线并保留旧基线。
基线名称、版本格式和审批角色应服从项目合同及组织质量体系。本文只提供管理方法，不规定一个通用编号方案。
版本状态怎么定义？
状态要表达对象在工作流中的“可做什么”，而不仅是“做到了哪一步”。项目可以采用自己的状态名称，但要把入口、出口、责任人、可见范围和回退方式写清楚。
| 示例状态 | 含义 | 进入条件 | 限制与下一步 |
|---|---|---|---|
| 草稿 | 正在编辑或等待补充的对象。 | 建立对象或提出修订。 | 可编辑、不可作为正式交付引用；需完成自检后提交评审。 |
| 待审核 | 作者认为内容和证据已准备好，等待指定人员审查。 | 自检、引用和媒体检查完成。 | 原则上冻结正文；问题退回草稿并保留意见。 |
| 已批准 | 通过项目规定的技术/质量审核，可被出版物引用。 | 审查意见关闭，审批记录完整。 | 修改必须产生新修订或走授权的更正流程。 |
| 已发布 | 已进入某个明确交付基线或现场版本。 | 发布前检查、目标环境验证和批准完成。 | 不应直接编辑；变更通过新版本、替换或补丁管理。 |
| 废止/撤回 | 不再用于新交付，或因问题从交付基线中移除。 | 替代对象生效或发布问题确认。 | 保留原因、替代关系、影响范围和可追溯记录。 |
“已批准”与“已发布”不一定相同：一个模块可以获批但尚未进入任何出版物基线；一个交付包也可能包含多个已批准对象和特定工具配置。状态命名应避免让读者误以为所有批准对象都已交付。
影响分析怎么做？
影响分析从变更对象沿关系向外检查，至少要覆盖直接引用、出版物结构、适用性、媒体、规则和目标格式。分析结论应说明“影响到哪里”和“需要做哪些验证”，而不是只写一个高/中/低等级。
| 分析维度 | 要问的问题 | 可能的验证范围 |
|---|---|---|
| 内容与引用 | 哪些 DM、PM、外部引用、交叉引用和任务步骤使用了该对象？ | 引用解析、目录路径、重复/缺失内容、读者导航。 |
| 适用性与配置 | 变更是否改变型号、批次、选装件、条件或筛选结果？ | 代表性配置、边界组合、空内容和错误内容检查。 |
| 媒体与交互 | 媒体尺寸、热点、图形标注、附件或播放能力是否受到影响？ | 图形清晰度、热点位置、视频/音频播放、附件打开。 |
| 规则与工具 | Schema、BREX、代码表、模板、转换器或阅读器行为会改变吗？ | 结构/规则校验、转换对比、渲染、检索和运行环境测试。 |
| 安全与合规 | 警告、注意、禁止、维护限制、权限或敏感信息边界是否变化？ | 安全信息复核、权限测试、审批和客户通知。 |
| 交付与回退 | 哪些输出、安装包、现场版本或培训材料需要更新？ | 候选包抽检、哈希更新、回退演练和发布说明。 |
影响范围不明确时，应采用保守的验证范围，并在变更记录中说明判断依据。小的文字修改也可能改变分页、交叉引用或安全语义；大的工具升级则不应只凭“兼容旧格式”声明缩小验证。
变更流程与回归检查
- 提出变更：记录来源、问题或需求、期望结果、紧急程度、涉及对象和建议生效时间。
- 初步分类：区分内容修订、媒体替换、规则变化、工具补丁、产品配置变化和交付环境变化。
- 完成影响分析：列出直接/间接受影响对象、风险、验证活动、责任人和预计回归范围。
- 技术与质量评审：确认修改方案、兼容性、适用性、安全影响、发布策略和回退方案。
- 在隔离环境实施：基于已批准基线创建工作副本，保存转换/编辑日志，避免直接覆盖正式基线。
- 执行回归检查：检查结构、规则、引用、目录、适用性、媒体、输出格式和目标环境行为。
- 审批并更新基线：关闭问题，生成新的版本清单、哈希和发布说明，由授权人批准。
- 通知与复盘：告知受影响的编制、审核、交付和现场人员；对紧急或高风险变更补充复盘。
最小回归集
- 修改对象本身的结构和业务规则校验。
- 直接引用它的 DM/PM、目录和导航路径。
- 至少一个典型配置与一个边界配置的适用性结果。
- 受影响媒体、警告/注意/禁止和关键程序步骤。
- 实际交付格式中的检索、渲染、打印或交互行为。
- 版本显示、哈希、安装/更新和回退结果。
变更记录应该留下什么？
| 记录字段 | 建议内容 | 作用 |
|---|---|---|
| 变更身份 | 唯一编号、提出人、日期、来源和优先级。 | 让沟通、审批和发布都指向同一件事。 |
| 对象与基线 | 受影响对象、当前版本、目标版本、所属基线和关系。 | 避免在错误版本或错误项目上实施。 |
| 理由与影响 | 变更原因、直接/间接影响、风险和不受影响的范围。 | 支持评审和验证范围决策。 |
| 实施与验证 | 操作人、工具/配置、日志、测试样例、问题及复测结果。 | 证明变更可复现并已验证。 |
| 批准与发布 | 审批人、批准时间、发布编号、生效范围、通知对象和回退点。 | 形成正式基线和后续审计证据。 |
常见管理风险
- 把“文件已保存”当成“配置已基线”，却没有工具、规则和交付环境记录。
- 只追踪数据模块版本，没有追踪媒体、出版物引用、适用性代码表和规则版本。
- 状态名称很多，但没有定义谁可以编辑、审批、发布或撤回。
- 影响分析只看直接引用，遗漏出版物、适用性、媒体、渲染和现场部署。
- 紧急修复直接覆盖正式包，导致旧版本、变更原因和回退步骤无法复现。
- 多个团队各自维护一份“最新清单”，没有指定权威配置库或批准基线。
常见问题
配置管理只需要给数据模块编号吗？
不够。配置管理还要识别出版物、媒体、规则、工具配置、产品配置和交付物，建立版本、状态、基线、关系和变更记录，使一次发布能够被重现。
草稿、已审核和已发布状态可以由项目自行定义吗？
项目可以在合同和质量体系允许的范围内定义工作流状态，但应明确每个状态的进入条件、可编辑范围、审批人、回退规则和对外发布含义，并在全项目统一使用。
数据模块改了以后，怎样判断哪些内容需要重新检查？
从直接引用、出版物目录、适用性条件、媒体关系、规则约束和交付格式等维度做影响分析。根据影响范围选择局部复核、相关出版物复测或完整回归，而不是只检查被修改的文件。
紧急变更可以跳过审批吗？
紧急流程可以压缩等待时间，但不应取消责任人、影响分析、验证证据和事后复盘。项目应提前定义紧急变更条件、临时批准方式、有效期和补充归档要求。
一个变更可以同时更新多个交付版本吗？
可以，但应分别确认每个交付版本的基线、适用范围、工具配置、回归结果和生效时间。共同的源数据修订不代表所有历史交付包都能直接替换。