信息（文档）与配置管理：修订间差异
（→配置管理系统） |
无编辑摘要 |
||
| （未显示同一用户的12个中间版本） | |||
| 第1行： | 第1行： | ||
=信息系统项目相关信息（文档）及其管理= | ==信息系统项目相关信息（文档）及其管理== | ||
==信息系统项目相关信息（文档）的含义和种类== | ===信息系统项目相关信息（文档）的含义和种类=== | ||
软件文档一般分为三类：开发文档、产品文档、管理文档。 | 软件文档一般分为三类：开发文档、产品文档、管理文档。 | ||
| 第23行： | 第23行： | ||
信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。 | 信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。 | ||
==信息系统项目相关信息（文档）管理的规则和方法== | ===信息系统项目相关信息（文档）管理的规则和方法=== | ||
（1）文档书写规范 | |||
== | （2）图标编号规则 | ||
（3）文档目录编写标准 | |||
（4）文档管理制度 | |||
==配置管理== | |||
配置管理包括 6 个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。 | |||
===配置项=== | ===配置项=== | ||
GB/T 11457-2006 对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。” | GB/T 11457-2006 对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。” | ||
| 第36行： | 第42行： | ||
所有配置项的操作权限应由 CMO （配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向 PM、CCB 及相关人员开放。 | 所有配置项的操作权限应由 CMO （配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向 PM、CCB 及相关人员开放。 | ||
===配置项状态=== | ===配置项状态=== | ||
配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。 | 配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。 | ||
===配置项版本号=== | ===配置项版本号=== | ||
| 第46行： | 第54行： | ||
（3）处于“修改”状态的配置项的版本号格式为 X.YZ。配置项正在修改时，一般只增大 Z 值，X.Y 值保持不变。当配置项修改完毕，状态成为“正式”时，将 Z 值设置为 0，增加 X.Y 值。参见上述规则（2）。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。 | （3）处于“修改”状态的配置项的版本号格式为 X.YZ。配置项正在修改时，一般只增大 Z 值，X.Y 值保持不变。当配置项修改完毕，状态成为“正式”时，将 Z 值设置为 0，增加 X.Y 值。参见上述规则（2）。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。 | ||
===配置项版本管理=== | ===配置项版本管理=== | ||
按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。 | |||
===配置基线=== | ===配置基线=== | ||
配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。 | 配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。 | ||
基线通常对应于开发过程中的里程碑, 一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线, 内部开发使用的基线一般称为构造基线。 | 基线通常对应于开发过程中的里程碑, 一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线, 内部开发使用的基线一般称为构造基线。 | ||
===配置库=== | ===配置库=== | ||
| 第72行： | 第85行： | ||
（2）按开发任务建立相应的配置库，适用于专业软件的开发组织。 | （2）按开发任务建立相应的配置库，适用于专业软件的开发组织。 | ||
===配置控制委员会=== | ===配置控制委员会=== | ||
配置控制委员会（Configuration Control Board, CCB）负责对配置变更作出评估、审批以及监督已批准变更的实施。 | |||
===配置管理员=== | ===配置管理员=== | ||
配置管理员（Configuration Management Officer, CMO）, 负责在整个项目生命周期中进行配置管理活动。 | 配置管理员（Configuration Management Officer, CMO）, 负责在整个项目生命周期中进行配置管理活动。 | ||
===配置管理系统=== | ===配置管理系统=== | ||
配置管理系统是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项的完备、清晰、一致和可追踪性，以及配置项状态的可控制性。 | 配置管理系统是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项的完备、清晰、一致和可追踪性，以及配置项状态的可控制性。 | ||
常用付费配置管理工具有：Rational ClearCase、Perforce、CA CCC、Havest Merant PVCS、Microsoft VSS, CVS。 | |||
常用的开源免费的软件配置管理工具有：SVN、GIT、CVS。 | |||
==制定配置管理计划== | ==制定配置管理计划== | ||
配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。 | |||
==配置标识== | ==配置标识== | ||
为系统选择配置项并在技术文档中记录配置项的功能和物理特征。 | |||
基本步骤 | |||
（1）识别需要受控的配置项 | |||
（2）为每个配置项指定唯一性的标识号 | |||
（3）定义每个配置项的重要特征 | |||
（4）确定每个配置项的所有者及其责任 | |||
（5）确定配置项进行配置管理的时间和条件 | |||
（6）建立和控制基线 | |||
（7）维护文档和组件的修订与产品版本之间的关系 | |||
==配置控制== | ==配置控制== | ||
===配置控制概念和主要任务=== | ===配置控制概念和主要任务=== | ||
配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准或否决变更，实现、验证和发布已修改的配置项。 | |||
===基于配置库的变更控制=== | ===基于配置库的变更控制=== | ||
#受控库复制产品库 | |||
#开发库提取受控库 | |||
#开发库提交受控库 | |||
#受控库更新产品库 | |||
==配置状态报告== | ==配置状态报告== | ||
配置状态报告也称配置状态统计, 其任务是有效地记录和报告配置管理所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关入员了解，以加强配置管理工作。 | |||
==配置审计== | ==配置审计== | ||
配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。 | |||
==发布管理和交付== | ==发布管理和交付== | ||
主要任务：有效控制软件产品和文档的发行和交付，在软件的生存期内妥善保存代码和文档的母拷贝。 | |||
2023年5月19日 (五) 02:09的最新版本
信息系统项目相关信息（文档）及其管理
信息系统项目相关信息（文档）的含义和种类
软件文档一般分为三类：开发文档、产品文档、管理文档。
（1）开发文档描述开发过程本身，基本的开发文档包括：可行性研究报告和项目任务书。需求规格说明。功能规格说明。设计规格说明，包括程序和数据规格说明。 开发计划。软件集成和测试计划。质量保证计划。安全和测试信息。
（2）产品文档描述开发过程的产物，基本的产品文档包括：培训手册。参考手册和用户指南。软件支持手册。产品手册和信息广告。
（3）管理文档记录项目管理的信息，例如：开发过程的每个阶段的进度和进度变更的记录。软件变更情况的记录。开发团队的职责定义。项目计划、项目阶段报告。配置管理计划。
文档的质量可以分为四级：
（1）最低限度文档（1 级文档）。适合开发工作最低于一个人月的开发者自用程序。
（2）内部文档（2 级文档）。可用于没有与其他用户共享资源的专用程序。
（3）工作文档（3 级文档）。适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
（4）正式文档（4 级文档）。适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要 4 级文档。4 级文档遵守 GB/T8567-2006 的有关规定。
信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。
信息系统项目相关信息（文档）管理的规则和方法
（1）文档书写规范
（2）图标编号规则
（3）文档目录编写标准
（4）文档管理制度
配置管理
配置管理包括 6 个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
配置项
GB/T 11457-2006 对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”
在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
所有配置项的操作权限应由 CMO （配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向 PM、CCB 及相关人员开放。
配置项状态
配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
配置项版本号
（1）处于“草稿”状态的配置项的版本号格式为 0.YZ，YZ 的数字范围为 01～99。随着草稿的修正，YZ 的取值应递增。YZ 的初值和增幅由用户自己把握。
（2）处于“正式”状态的配置项的版本号格式为 X.Y，X 为主版本号，取值范围为1～9。Y 为次版本号，取值范围为 0～9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为 1.0，1.1，……。当附件的变动积累到一定程度时，配置项的 Y 值可适量增加，Y 值增加一定程度时，X 值将适量增加。当配置项升级幅度比较大时，才允许直接增大 X 值。
（3）处于“修改”状态的配置项的版本号格式为 X.YZ。配置项正在修改时，一般只增大 Z 值，X.Y 值保持不变。当配置项修改完毕，状态成为“正式”时，将 Z 值设置为 0，增加 X.Y 值。参见上述规则（2）。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
配置项版本管理
按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
配置基线
配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
基线通常对应于开发过程中的里程碑, 一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线, 内部开发使用的基线一般称为构造基线。
配置库
配置库（Configuration Library）存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。
配置库可以分开发库、受控库、产品库 3 种类型。
（1）开发库, 也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库是开发人员的个人工作区，由开发人员自行控制，无需对其进行配置控制。
（2）受控库, 也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
（3）产品库, 也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
配置库的建库模式有两种：
（1）按配置项的类型分类建库，适用于通用软件的开发组织。
（2）按开发任务建立相应的配置库，适用于专业软件的开发组织。
配置控制委员会
配置控制委员会（Configuration Control Board, CCB）负责对配置变更作出评估、审批以及监督已批准变更的实施。
配置管理员
配置管理员（Configuration Management Officer, CMO）, 负责在整个项目生命周期中进行配置管理活动。
配置管理系统
配置管理系统是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项的完备、清晰、一致和可追踪性，以及配置项状态的可控制性。
常用付费配置管理工具有：Rational ClearCase、Perforce、CA CCC、Havest Merant PVCS、Microsoft VSS, CVS。
常用的开源免费的软件配置管理工具有：SVN、GIT、CVS。
制定配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。
配置标识
为系统选择配置项并在技术文档中记录配置项的功能和物理特征。
基本步骤
（1）识别需要受控的配置项
（2）为每个配置项指定唯一性的标识号
（3）定义每个配置项的重要特征
（4）确定每个配置项的所有者及其责任
（5）确定配置项进行配置管理的时间和条件
（6）建立和控制基线
（7）维护文档和组件的修订与产品版本之间的关系
配置控制
配置控制概念和主要任务
配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准或否决变更，实现、验证和发布已修改的配置项。
基于配置库的变更控制
- 受控库复制产品库
- 开发库提取受控库
- 开发库提交受控库
- 受控库更新产品库
配置状态报告
配置状态报告也称配置状态统计, 其任务是有效地记录和报告配置管理所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关入员了解，以加强配置管理工作。
配置审计
配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。
发布管理和交付
主要任务：有效控制软件产品和文档的发行和交付，在软件的生存期内妥善保存代码和文档的母拷贝。