信息系统项目相关信息(文档)种类

软件文档一般分为三类:开发文档、产品文档、管理文档。
1.开发文档描述开发过程本身，基本的开发文档包括:

• 可行性研究报告和项且任务书。
• 需求规格说明。
• 功能规格说明。
• 设计规格说明，包括程序和数据规格说明。
• 开发计划。
• 软件集成和测试计划。
• 质量保证计划。
• 安全和测试信息。

2.产品文档描述开发过程的产物，基本的产品文档包括:

• 培训手册。
• 参考手册和用户指南。
• 产品手册和信息广告。

3.管理文档记录项目管理的信息，例如:

• 开发过程的每个阶段的进度和进度变更的记录。
• 软件变更情况的记录。
• 更发团队的职责定义。
• 项目计划、项目阶段报告。
• 配置管理计划。

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

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

信息系统项目文档管理的规则和方法

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

配置管理

配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。在GB/T 11457--2006中， 将“配置管理”正式定义为:“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
尽管硬件配置管理和软件配置管理的实现有所不同，配置管理的概念可以应用于各种信息系统集成项目。
配置管理包括6个主要活动:制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

配置项

GB/T 11457- -2006 对配置项的定义为:“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待”
典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理
所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节(部分)记录对象的标识信息。在引入配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中
在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置项两类，例如，
基线配置项可能包括所有的设计文档和源程序等:
非基线配置项可能包括项目的各类计划和报告等。
所有配置项的操作权限应由CMO(配置管理员)严格管理，基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向PM、CCB及相关人员开放。

配置项状态

配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
配置项状态变化如图14-2所示。

配置项版本号

配置项的版本号规则与配置项的状态相关。
(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)。

配置项版本管理

对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

配置基线

配置基线(常简称为基线)由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。
基线通常对应于开发过程中的里程碑(Milestone)，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线(Release)， 内部开发使用的基线一般称为构造基线(Build)。

配置库

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

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

配置控制委员会

配置控制委员会(Configuration Control Board, CCB)，负责对配置变更做出评估、审批以及监督已批准变更的实施。
CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。

配置管理员

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

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

配置管理系统

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

确定配置管理目标

软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。高级项目经理应确保以下配置管理目标得以实现。

• 确保软件配置管理计划得以制订，并经过相关人员的评审和确认。
• 应该识别出要控制的项目产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员失取
• 应制定控制策略，以确保项目产品在受控制范围内更改。
• 应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。

日常配置管理活动

制订配置管理计划

配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。
配置管理计划的主要内容为:
(1)配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。
(2)实施这些活动的规范和流程。
(3)实施这些活动的进度安排。
(4)负责实施这些活动的人员或组织，以及他们和其他组织的关系。

配置标识

配置标识(Configuration Identifcation)也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。
配置识别是配置管理员的职能，基本步骤如下，
(1)识别需要受控的配置项。
(2)为每个配置项指定唯一性的标识号。
(3)定义每个配置项的重要特征。
(4)确定每个配置项的所有者及其责任。
(5)确定配置项进入配置管理的时间和条件。
(7)维护文档和组件的修订与产品版本之间的关系。

配置控制

配置控制即配置项和基线的变更控制，包括下述任务:标识和记录变更申请，分析和评价变更，批准或否决申请，实现、验证和发布已修改的配置项。
1)变更申请
2)变更评估
CCB负责组织对变更申请进行评估并确定以下内容。

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

3)通告评估结果
4)变更实施
5)变更验证与确认
6)变更的发布
7)基于配置库的变更控制
现以某软件产品升级为例，简述其流程。
(1)将待升级的基线(假设版本号为V2.1)从产品库中取出，放入受控库。
(2)程序员将欲修改的代码段从受控库中检出(Check out), 放入自己的开发库中进行修改。代码被Check out后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。
(3)程序员将开发库中修改好的代码段检入(Check in)受控库。Check in后，代码的“锁定”被解除，其他程序员可以Check out该段代码了。
(4)软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保存)。

配置状态报告

配置状态报告(Configuration Status Reporting)也称配置状态统计(Configuration Status Accounting),其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
配置状态报告应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。配置状态报告应定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况
配置状态报告还可供项目经理和CCB追踪变更的情况，

配置审计

配置审计(Configuration Audit)也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求一不允许出现任何混乱现象，例如:

• 防止向用户提交不适合的产品，如交付了用户手册的不正确版本。
• 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
• 找出各配置项间不匹配或不相容的现象。
• 确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
• 确认记录和文档保持着可追溯性。

1)功能配置审计
功能配置审计(Functional Configuration Audit)是审计配置项的一致性(配置项的实际功效是否与其需求一致)，具体验证以下几个方面。

• 配置项的开发已圆满完成。
• 配置项已达到配置标识中规定的性能和功能特征。
• 配置项的操作和支持文档已完成并且是符合要求的。

2)物理配置审计
物理配置审计(Physical Configuration Audit)是审计配置项的完整性( 配置项的物理存在是否与预期一致)，具体验证如下几个方面。

• 要交付的配置项是否存在。
• 配置项中是否包含了所有必需的项目。

发布管理和交付

(1)存储。
(2)复制。
(3)打包。
(4)交付。
(5)重建。