一、配置数据库分类
配置数据库根据软件开发阶段的不同，分为三类，用于有效管理软件资产：
开发库（Development Library）
- 供开发人员在开发过程中使用。
- 内容频繁变更，允许自由修改。
- 管理控制较为宽松，通常不强制版本控制或变更审批。
- 适用于代码编写、单元测试等早期活动。
受控库（Controlled Library / Software Configuration Library）
- 在某一开发阶段结束时形成，包含该阶段的“阶段产品”。
- 包括文档、源码、设计说明等计算机与人工可读信息。
- 实施严格的变更控制和版本管理，所有修改需经过评审和批准。
- 是软件配置管理（SCM）的核心对象，确保一致性与可追溯性。
产品库（Product Library）
- 软件通过系统测试后的最终成果集合。
- 用于交付用户或现场部署安装。
- 具有最高级别的控制，仅允许正式发布版本入库。
- 支持后期维护、版本回溯和客户支持。
二、软件风险管理
软件风险的本质是不确定性带来的潜在损失，需从发生概率与影响程度两个维度进行量化评估与应对。
1. 项目风险
- 影响：项目进度延误、成本超支、资源冲突。
- 主要因素：
- 预算不足或分配不合理
- 进度安排不现实
- 人员流动大或技能不足
- 需求频繁变更
- 项目规模庞大或结构复杂
2. 技术风险
- 影响：软件质量下降、交付延迟、难以维护。
- 主要因素：
- 设计缺陷或架构不合理
- 实现难度高（如算法复杂）
- 接口兼容性问题
- 测试覆盖不足或验证困难
- 规格说明书模糊或存在歧义
- 使用未经验证的新技术或陈旧技术
3. 商业风险
- 影响：产品无法盈利或被市场淘汰。
- 五类核心风险：
- 市场风险：产品无市场需求或竞争激烈。
- 策略风险：产品偏离公司长期发展战略。
- 销售风险：缺乏有效的销售渠道或客户接受度低。
- 管理风险：高层管理者中途撤资或失去兴趣。
- 预算风险：资金链断裂或人力资源无法持续保障。
4. Charette 的风险分类模型
- 已知风险：可通过当前项目计划和环境明确识别的风险（如交付周期过短）。
- 可预测风险：基于历史项目经验可以预见的风险（如团队成员离职率高）。
- 不可预测风险：突发性事件，难以提前识别（如关键人员突然病假、自然灾害）。
建立有效的受控库变更控制流程是软件配置管理（SCM）的核心环节，旨在确保所有对受控库中配置项的修改都经过评审、授权、记录和验证，从而保障软件产品的完整性、一致性和可追溯性。以下是构建该流程的关键步骤与实践：
一、定义受控库范围与配置项
- 明确纳入对象：确定哪些成果物属于受控库管理，如需求文档、设计说明书、源代码、测试用例、构建版本等。
- 标识配置项（CI）：为每个配置项赋予唯一标识符，并建立配置结构树（如父子关系、依赖关系）。
二、建立基线（Baseline）
- 在关键里程碑（如需求冻结、设计完成、系统测试通过）创建基线。
- 基线是“已批准的稳定状态”，任何后续变更必须通过正式流程进行。
示例： 需求基线 → 设计基线 → 编码基线 → 测试基线三、制定变更控制流程
1. 提交变更请求（Change Request, CR）
- 开发人员或相关方提交《变更申请单》，说明变更原因、影响范围、预期效果。
- 使用工具支持（如JIRA、ClearQuest）实现电子化流程。
2. 变更影响分析
- 配置管理员协同技术负责人评估：
- 对功能、性能、接口的影响；
- 对进度、成本、资源的影响；
- 是否需要同步修改其他配置项。
3. 变更评审与决策（CCB 审批）
- 成立变更控制委员会（CCB, Change Control Board），成员包括项目经理、架构师、测试负责人、配置管理员等。
- CCB 定期召开会议，决定是否批准、拒绝或推迟变更。
- 决策结果需书面记录并通知相关人员。
4. 实施变更
- 获批后，由指定人员在隔离环境中实施变更（如分支开发）。
- 更新配置项版本号（遵循版本命名规范，如 v2.1.0）。
5. 验证与测试
- 变更后的配置项必须经过单元测试、集成测试或回归测试验证。
- 确保未引入新的缺陷且满足原定目标。
6. 入库与更新基线
- 测试通过后，将新版本配置项正式纳入受控库。
- 必要时建立新的基线以反映最新稳定状态。
7. 记录与审计
- 所有变更活动必须完整记录在案，包括：
- 变更编号、申请人、时间；
- 审批意见、实施人、验证结果；
- 关联的配置项版本。
- 支持后期审计、问题追溯和合规检查。
四、工具与技术支持
- 使用配置管理工具（如 Git + 权限控制、SVN、IBM Rational ClearCase、Azure DevOps）实现：
- 版本控制；
- 分支/合并策略；
- 访问权限管理（只读/写权限）；
- 变更追踪与报告生成。
五、角色与职责明确
| 角色 | 职责 |
|---|---|
| 配置管理员（CMO） | 维护库结构、执行入库操作、生成配置状态报告 |
| 项目负责人 | 参与CCB，协调资源 |
| 开发/测试人员 | 提出变更、实施修改、配合验证 |
| CCB | 最终审批重大变更 |
六、持续改进
- 定期回顾变更流程效率（如平均审批周期、变更失败率）；
- 收集反馈优化表单、流程节点或工具使用体验；
- 结合CMMI或ISO 9001标准进行过程成熟度提升。
✅最佳实践建议：
- 小变更也需走流程，避免“绕道”破坏一致性；
- 强制要求所有交付物纳入配置管理；
- 自动化触发测试与构建，减少人为错误；
- 建立配置状态报告制度，定期发布变更摘要。
