配置状态报告

1. 相关信息是从《配置状态记录》中提取。
2. 包括所有的配置项模块(多级)、配置项描述、配置标识、当前和过去的版本号、包含元素(针对代码产品)、批准时间、配置时间、发布日期、控制基线及版本、变更请求等内容。
3. 所有提交的变更请求/问题报告的状态。

报告时机：

1. 每次有新的配置项纳入基线时。
2. 原有配置项更新为新版本时。
3. 每次变更批准时。
4. 每次基线库做出发布时。

报告频度：

1. 每周、没两周定期的报告一次。
2. 也可根据项目具体情况进行裁剪。
3. 报告的时间应由SCM负责人确定时间并记录下来。

内部所有受到影响的组合个人（可以以邮件的方式）

变更状态报告

1. 相关信息从《变更与问题日志》中提取。
2. 包括基线域和开发域的变更日志。
3. 日志中内容包括：变更或问题编号、变更描述、请求人、当前状态(如公开的、在评价的、批准的变更)、状态日期、受影响项(包括版本号)、责任人、计划完成日期、实际完成日期、纳入基线日期、批准人，每次提取的状态为多个变更状态中的当前的状态。
4. 所有变更状态当前的统计结果。

报告时机：

每次变更批准时，配置人员应及时发E_mail(BQQ)通知项目组所有人员，让所有人都了解变更情况。

报告频度：

1. 每周或每两周报告一次，作为配置状态报告的一部分。
2. 根据项目阶段的不同也可定义报告的频度。如需求阶段和代码阶段报告发布的频度是不同的。
3. SCM负责人确定并记录。
4. 可根据需要随时进行报告。

内部所有受到影响的组合个人

基线发布报告

基线审计报告

基线发布报告

基线审计报告

包含基线版本描述、基线变更描述。

• 基线版本描述：

1. 包括本次基线发布的所有配置项的名称、配置标识、当前版本和修改次数。
2. 已关闭的和尚处在开发的问题及状态统计
3. 本次基线和上次基线的区别，即解决了哪些问题和未解决的问题有哪些。
4. 关于发布的注释、限制、假设和任何其他重要信息。

• 基线变更描述

本基线的所有历史变更的名称、版本号、发布时间和发布人。

包括基线审计报告、基线内容清单、基线审计检查单三部分。

1. 基线设计报告：项目名称、编号、审核基线、审计时间、审计目的、审计结果、审计人员签字。
2. 基线内容清单：配置项标识、版本号、配置日期、完成人、审计状况。

发布时机：

1. 各阶段的产品完成后，纳入到基线库中，并进行基线发布。
2. 发布时间要参照项目开发计划中阶段产品完成的时间来确定。
3. SCM负责人要把发布时间记录。

审计时机：（共两次）

1. 第一次是在系统测试前。
2. 第二次是在对客户正式交付产品之前。
3. 审计报告要在完成审计之后，及时发布。
4. SCM负责人确定并记录审计时间。

内部所有受到影响的组合个人