700字范文 > 《系统集成项目管理》第十五章信息（文档）和配置管理

《系统集成项目管理》第十五章信息（文档）和配置管理

时间：2022-01-26 04:54:38

文章目录

一、信息系统项目相关信息（文档）及其管理1、信息系统项目相关信息（文档）2、信息系统项目相关信息（文档）管理的规则和办法二、配置管理1、配置管理的概念（1）配置项（2）配置项状态（3）配置项版本号（4）配置项版本管理（5）配置基线（6）配置库（7）配置库权限设置（8）配置控制委员会（CCB）（9）配置管理员（CMO）（10）配置管理系统2、制定配置管理计划3、配置标识4、配置控制（1）变更申请（2）变更评估（3）通告评估结果（4）变更实施（5）变更验证与确认（6）变更的发布（7）基于配置库的变更控制5、配置状态报告6、配置审计（1）功能配置审计（2）物理配置审计7、发布管理和交付三、补充1、各角色在配置管理活动中的权限

一、信息系统项目相关信息（文档）及其管理

1、信息系统项目相关信息（文档）

信息系统相关信息（文档）：是指某种数据媒体和其中所记录的数据。

它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西。在软件工程中，文档常常用来表示对活动、需求、过程或结果，进行描述、定义、规定、报告或认证的任何书面或图示的信息（包括纸质文档和电子文档）。

信息系统项目相关信息（文档）种类：开发文档、产品文档、管理文档。

开发文档：描述开发过程本身，基本的开发文档是：可行性研究报告和项目任务书；需求规格说明；功能规格说明；设计规格说明，包括程序和数据规格说明；开发计划；软件集成和测试计划；质量保证计划；安全和测试信息。产品文档：描述开发过程的产物，基本的产品文档包括：培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告。管理文档：记录项目管理的信息，例如：开发过程的每个阶段的进度和进度变更的记录；软件变更情况的记录；开发团队的职责定义。

文档的质量可以分为四级：

最低限度文档（1级文档）：适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。内部文档（2级文档）：可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。正式文档（4级文档）：适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档遵守GB 8567的有关规定。

2、信息系统项目相关信息（文档）管理的规则和办法

信息系统文档的规范化管理：主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。

（1）文档书写规范。遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。

例如，在程序的开始要用统一的格式包含程序名称、程序功能、调用和被调用的程序、程序设计人等。

（2）图表编号规则。对图表进行有规则的编号，可以方便图表的查找。图表的编号一般采用分类结构。根据生命周期法的5个阶段，可以给出如下图所示的分类编号规则。

（3）档目录编写标准。文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。

文档编号一般为分类结构，可以采用同图表编号类似的编号规则。文档名称要完整规范。格式或载体指的是原始单据或报表、磁盘文件、磁盘文件打印件、大型图表、重要文件原件、光盘存档等。

（4）文档管理制度。主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。

建立文档的相关规范是指文档书写规范、图表编号规则和文档目录编写标准等。文档的借阅应该进行详细的记录，并且需要考虑借阅人是否有使用权限。在文档中存在商业秘密或技术秘密的情况下，还应注意保密。特别要注意的是，项目干系人签字确认后的文档要与相关联的电子文档一一对应，这些电子文档还应设置为只读。

二、配置管理

配置管理：是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。

在GB/T 11457-中，将**“配置管理”**正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”配置管理包括6个主要活动：制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

1、配置管理的概念

（1）配置项

配置项的定义（GB/T11457-）为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”

典型配置项：包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在配置库中。

在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置项两类

基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：

基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。

（2）配置项状态

配置项的状态：可分为草稿、正式和修改三种。

配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为**“正式”**。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。

（3）配置项版本号

配置项的版本号规则与配置项的状态相关。

“草稿”状态：的配置项的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。“正式”状态：的配置项的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1，…。当附件的变动积累到一定程度时，配置项的Y值玎适量增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，XY值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为O，增加X.Y值。参见上述规则(2)。

（4）配置项版本管理

配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。

在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的：是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

（5）配置基线

**配置基线（常简称为基线）**由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。

基线的构成：一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。基线通常对应于开发过程中的里程碑( Milestone)，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线( Release)，内部开发使用的基线一般称为构造基线(Build)。对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

（6）配置库

配置库(Configuration Library)：存放配置项并记录与配置项相关的所有信息。

配置库可以分开发库、受控库、产品库3种类型。

开发库（Development Library），也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。受控库（Controlled Library），也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。若修改需要进行变更控制过程。产品库(Product Library)，也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。

配置库的建库模式有两种：按配置项类型建库和按任务建库。

按配置项的类型分类建库，适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。按开发任务建立相应的配置库，适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。

（7）配置库权限设置

配置库的权限设置主要是解决：库内存放的配置项什么人可以“看”、什么人可以“取”、什么人可以“改”、什么人可以“销毁”等问题。

配置管理员负责为每个项目成员分配对配置库的操作权限.

（8）配置控制委员会（CCB）

配置控制委员会(Configuration Control Board，CCB)，负责对配置变更做出评估、审批以及监督已批准变更的实施。

CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。

通常，CCB不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理计划审批、基线设立审批、产品发布审批等。

（9）配置管理员（CMO）

配置管理员(Configuration Management Oflicer，CMO)，负责在整个项目生命周期中进行配置管理活动，具体有：

编写配置管理计划。建立和维护配置管理系统。建立和维护配置摩。配置项识别。建立和管理基线。版本管理和配置控制。配置状态报告。配置审计。发布管理和交付。对项目成员进行配置管理培训。

（10）配置管理系统

配置管理系统：用来进行配置管理的软件系统。

目的：通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项（包括各种文档、数据和程序）的完备、清晰、一致和可追踪性，以及配置项状态的可控制性。

2、制定配置管理计划

配置管理计划：对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。

配置控制委员会（CCB）负责审批该计划。

配置管理计划的主要内容为：

配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付；实施这些活动的规范和流程；实施这些活动的进度安排；负责实施这些活动的人员或组织，以及他们和其他组织的关系。

3、配置标识

配置标识( Configuration ldentifcation)（配置识别），包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。

配置标识是配置管理员（CMO）的职能，基本步骤如下。

识别需要受控的配置项。为每个配置项指定唯一性的标识号。定义每个配置项的重要特征。确定每个配置项的所有者及其责任。确定配置项进入配置管理的时间和条件。建立和控制基线。维护文档和组件的修订与产品版本之间的关系。

4、配置控制

配置控制：配置项和基线的变更控制。

包括下述任务：标识和记录变更申请，分析和评价变更，批准或否决申请，实现、验证和发布已修改的配置项。

（1）变更申请

变更申请主要就是陈述：what，why，how。

相关流程：相关人员如项目经理填写变更申请表，说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，并提交给配置控制委员会（CCB）。

（2）变更评估

配置控制委员会（CCB）负责组织对变更申请进行评估并确定以下内容。

变更对项目的影响。变更的内容是否必要。变更的范围是否考虑周全。变更的实施方案是否可行。变更工作量估计是否合理。

CCB决定是否接受变更，并将决定通知相关人员。

（3）通告评估结果

CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。

如果变更申请得到批准，应该及时把变更批准信息和变更实施方案通知给那些正在使用受影响的配置顼和基线的干系人。如果变更申请被否决，宜通知有关干系人放弃该变更申请。

（4）变更实施

项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息。

（5）变更验证与确认

项目经理指定人员对变更后的配置项进行测试或验证。

项目经理应将变更与验证的结果提交CCB，由其确认变更是否已经按要求完成。

（6）变更的发布

配置管理员将变更后的配置项纳入基线。

配置管理员将变更内容和结果通知相关人员，并做好记录。

（7）基于配置库的变更控制

现以某软件产品升级为例，简述其流程。检入(cheek in)

将待升级的基线（假设版本号为V2.1）从产品库中取出（复制操作)，放入受控库。程序员将欲修改的代码段从受控库中检出(cheek out)，放入自己的开发库中进行修改。代码被Check out后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。

(3)程序员将开发库中修改好的代码段检入(cheek in)受控库。Cheek in后，代码的“锁定”被解除，其他程序员可以Check out该段代码了。

(4)软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保存）。

5、配置状态报告

配置状态报告（Confzguration Status Reporting）也称配置状态统计(Configuration Status ACCounting)，其任务是有效地记录和报告管理配置所需要的信息。

目的：及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。配置状态报告应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。配置状态报告应定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况。

配置状态报告应该包含以下内容：

每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。每个变更申请的状态和已批准的修改的实施状态。每个基线的当前和过去版本的状态以及各版本的比较。其他配置管理过程活动的记录。

6、配置审计

配置审计(Configuration Audit）（配置审核或配置评价）

包括：功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。目的：确保项目配置管理的有效性，体现了配置管理的最根本要求——不允许出现任何混乱现象，例如：防止向用户提交不适合的产品，如交付了用户手册的不正确版本；发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更；找出各配置项间不匹配或不相容的现象；确认配置项已在所要求的质量控制审核之后纳入基线并入库保存；确认记录和文档保持着可追溯性。