信息文档管理（简单了解）
信息系统相关信息(文档)是指某种数据媒体和其中所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西。在软件工程中，文档常常用来表示对活动、需求、过程或结果，进行描述、定义、规定、报告或认证的任何书面或图示的信息(包括纸质文档和电子文档)。
信息系统项目相关文档种类：
1.开发文档：描述开发过程本身。
①可行性研究和项目任务书；②需求规格说明；③功能规格说明；④设计规格说明，包括程序和数据规格说明；⑤开发计划；⑥软件集成和测试计划；⑦质量保证计划；⑧安全和测试信息。
2.产品文档：描述开发过程的产物。
①培训手册；②参考手册和用户指南；③软件支持手册；④产品手册和信息广告
3.管理文档：记录项目管理的信息。
①开发过程的每个阶段的进度和进度变更的记录；②软件变更情况的记录；③开发团队的职责定义；④项目计划、项目阶段报告；⑤配置管理计划
开餐馆
文档质量可以分为四级：
(1)最低限度文档(1级文档)，适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。【1.低于一人月】
(2)内部文档(2级文档)，可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。【2.无共享资源】
(3)工作文档(3级文档)，适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。【3.联合开发】
(4)正式文档(4级文档)，适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质(如工资计算)的程序需要4级文档。4级文档遵守GB8567-2006计算机软件文档编制规范的有关规定。【4.正式发行】
信息系统文档管理的规则和方法
管理信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面
配置管理（重点）
配置管理是什么，为什么做配置管理
配置管理是为了系统的控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。在GB/T11457-2006中，将“配置管理”正式定义为“应用技术的和管理的指导和监督方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。
☆☆☆配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付
情形一：没有配置及变更管理的研发文档会不一致（大家拿到的文档不一致）
情形二：没有配置及变更管理的代码可能会混乱不堪（多人维护同一段代码错乱）
配置项
GB/T 11457-2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。
配置项的内容主要包括：
- 外部交付的软件产品和数据；
- 指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
【每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等】
配置项分类及权限
- 基线与非基线配置项
在信息系统的开发流程中需加以控制的配置项可分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等（受严格变更控制），非基线配置项可能包括项目的各类计划和报告等 - 配置项操作权限
所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
配置项状态
配置项的状态可分为“草稿”“正式”和“修改”三种。
1.配置项刚建立时，其状态为“草稿”。
2.配置项通过评审后：其状态变为“正式”
3.此后若更改配置项，则其状态变为“修改”。
4.当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
配置项版本号
配置项版本号说明如下：
一、处于“草稿”状态的配置项的版本号格式为：O.Z。例如：V0.72
- YZ数字范围为01~99。
- 随着草稿的不断完善，YZ的取值应递增。YZ的初值和增幅由开发者自己把握。
二、处于“正式发布”状态的配置项的版本号格式为：X.Y。例如：V1.0
- X为主版本号，取值范围为1——9。Y为次版本号，取值范围为0——9。
- 配置项第一次“正式发布”时，版本号为1.0。
- 如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。例如V1.1
- 只有当配置项版本升级幅度比较大时，才允许增大X值。例如V2.0
三、处于“正在修改”状态的配置项的版本号格式为：X.YZ。例如：V1.72
- 配置项在修改时，一般只增大Z值，XY值保持不变。
- 当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。
对配置项的任何修改都将产生新的版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到配置项的任何版本。
配置基线
基线(Baseline) 由一组配置项组成， 这些配置项构成了一个相对稳定的逻辑实体(也由CCB审核) 。基线中的配置项被“冻结”了，不能再被任何人随意修改(例如，跟踪和控制变更，像评审通过后的需求文件等)。对基线的变更必须遵循正式的变更控制程序。
基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线 (Release) ，内部开发使用的基线一般称为构造基线(Build)
一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。
对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。
建立基线还可以有如下好处：
1.基线为开发工作提供了一个定点和快照。
2.新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目(在主要分支上)所进行的变更进行隔离。
3.当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
4.可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。
配置库
配置库：也称配置项库configuration item repository) ， 存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。
主要作用：
1.记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的内容。
2.利用库中的信息可评价变更的后果，这对变更控制有着重要的意义。
3.从库中可提取各种配置管理过程的管理信息。
利用库中的信息可回答许多配置管理的问题，例如：
1.哪些客户已提取了某个特定的系统版本?
2.运行一个给定的系统版本需要什么硬件和系统软件?
3.一个系统到目前已生成了多少个版本，何时生成的? 【主要是版本的相关问题】
4.如果某一特定的构件变更了，会影响到系统的哪些版本?
5.一个特定的版本曾提出过哪几个变更请求?
6.一个特定的版本有多少己报告的错误?
使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
配置库包括动态库(开发库)(受控库(主库)、静态库产品库)
开发库(动态库、也称为动态库、程序员库或工作库)：用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。
动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制
受控库(主库)：包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
产品库(静态库、发行库、软件仓库)：包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
配置库的建库模式：
配置库的建库模式有两种：按配置项类型建库和按任务建库。
(1)按配置项的类型分类建库，适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。【通用产品】
(2)按开发任务建立相应的配置库，适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。【定制产品】
软件配置管理
- 软件产品配置（定制）
用户1：ABCDEF模块
用户2：ABCDEGH模块
按用户配置
优点：研发实现简单，不容易冲突；
缺点：配置管理复杂、版本多，产品功能不通用 - 通用软件配置
所有用户的系统及功能，产品都在一个产品配置里，既包括共性部分，也包括个性部分。
优点：配置管理简单，版本控制统一容易，产品通用。
缺点：研发时需要考虑共性和个性部分，容易冲突不灵活，研发管理复杂。
配置库权限设置
配置库的操作权限：
受控库权限设置：
产品库权限设置：
CCB及CMO及配置管理系统
配置控制委员会(Conf uration ControlBoard， CCB) 负责对配置变更做出评估、审抽以及监熠已批准变更的实施。
CCB建立在项目级， 其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人， 甚至只是兼职人员。
通常， CCB不只是控制配置变更， 而是负有更多的配置管理任务，例如：配置管理计划审批、基线设立审批、产品发布审批等。
配置管理员(Configuration Management Officer， CMO) ， 负责在整个项目生命周期中进行配置管理活动，具体有：
- 编写配置管理计划。
- 建立和维护配置管理系统。
- 建立和维护配置库。
- 配置项识别。
- 建立和管理基线。
- 版本管理和配置控制。
- 配置状态报告。
- 配置审计。
- 发布管理和交付。
- 对项目成员进行配置管理培训。
配置管理系统：是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项(包括各种文档、数据和程序)的完备、清晰、一致和可追踪性，以及配置项状态的可控制性。
日常配置管理活动
助记：计标控报审发
1. 制定配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。配置管理计划的主要内容为：
(1)配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。
(2)实施这些活动的规范和流程。
(3)实施这些活动的进度安排。
(4)负责实施这些活动的人员或组织，以及他们和其他组织的关系。
2. 配置标识
配置标识(Configuration Identification) 也称配置识别， 包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。
配置标识是配置管理员的职能，基本步骤如下：
(1)识别需要受控的配置项。
(2)为每个配置项指定唯一性的标识号
(3)定义每个配置项的重要特征。
(4)确定每个配置项的所有者及其责任。
(5)确定配置项进入配置管理的时间和条件
(6)建立和控制基线
(7)维护文档和组件的修订与产品版本之间的关系。
3. 配置控制
配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准和否决申请，实现、验证和发布已修改的配置项。
具体过程为：变更申请——变更评估——通告评估结果——变更实施——变更验证与确认——变更的发布——基于配置库的变更控制
如何解决多个开发人员修改同一部件导致的混乱？
现以某软件产品升级为例，简述其流程。
(1)将待升级的基线(假设版本号为V2.1)从产品库中取出，放入受控库。
(2) 程序员将欲修改的代码段从受控库中检出(Checkout) ， 放入自己的开发库中进行修改。代码被Checkout后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改， 乙就无法Checkout。
(3) 程序员将开发库中修改好的代码段检入(Check in) 受控库。Check in后， 代码的“锁定”被解除， 其他程序员可以Checkout该段代码了。
(4)软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保存)
4. 配置状态报告
配置状态报告(Configuration Status Reporting) 也称配置状态统计(Configuration Statos Accounting) ， 其任务是有效地记录和报告管理配置所需要的信息”。 目的是及时准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
内容
(1)每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
(2)每个变更申请的状态和已批准的修改的实施状态。
(3)每个基线的当前和过去版本的状态以及各版本的比较。
(4)其他配置管理过程活动的记录。
回答的问题
各种有用信息：
·程序P13的1.6版在哪个备份中可以使用?
·在发行基线5.1和发行基线5.2之间实现了哪些变更请求?
·在发行基线5.2中哪些程序更改过了?
·在变更请求671中要对哪些配置项进行更改?在变更前和变更后，这些程序单元的版本是什么?是否所有的变更都完成并入库了?
配置状态报告还可供项目经理和CCB追踪变更的情况， 可以用来回答如下问题。
·某个变更请求是否已被批准?
·某个已批准的变更请求目前处于什么状态?
·某个已完成的变更投入了多少时间和工作量?
·某个配置项与哪几个变更请求有关?
5. 配置审计
配置审计(Configuration Audit) 也称配置审核或配置评价， 包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。
实施配置审核的意义：配置审核的实施是为了确保项目配置管理的有效性，体现配置管理的最根本要求―-不允许出现任何混乱现象，例如：
·防止出现向用户提交不适合的产品，如交付了用户手册的不正确版本。
·发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
·找出各配置项间不匹配或不相容的现象。
·确认配置项已在所要求的质量控制审查之后作为基线入库保存。
·确认记录和文档保持着可追溯性。
配置审计的内容：
1.功能配置审计：功能配置审计(Functional Configuration Audit) 是审计配置项的一致：性(配置项的实际功效是否与其需求一致)，具体验证以下几个方面：
·配置项的开发已圆满完成。
·配置项已达到配置标识中规定的性能和功能特征。
·配置项的操作和支持文档己完成并且是符合要求的。
2.物理配置审计：物理配置审计(Physical Configuration Audit) 是审计配置项的完整性(配置项的物理存在是否与预期一致)，具体验证如下几个方面：
·要交付的配置项是否存在。
·配置项中是否包含了所有必需的项目
6. 发布和交付
发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在
软件产品的生存期内妥善保存代码和文档的母拷贝。
(1)存储。确保存储的配置项的完整性
(2)复制。复制是用拷贝方式制造软件的阶段。
(3)打包。应确保按批准的规程制备交付的介质。【如打包安装程序和帮助手册在一个光盘】
(4)交付。供方应按合同中的规定交付产品或服务。
(5)重建。应能重建软件环境
文档管理、配置管理工具
常用的软件配置管理工具分为两大类，一类是付费商业软件，一类是开源软件。
1.常用付费软件配置管理工具有：
·Rational ClearCase
·Perforce (现属IBM， 集中式版本控制工具)
·CACCC/Have st
·Have st Merant PVCS
·Microsoft VSS
2.常用的开源免费的软件配置管理工具有：
·SVN(代码版本管理软件)
·GIT(开源分布式版本控制工具)
·CVS(并发版本系统)
目前在国内IT领域使用最广泛的， 当属开源免费软件SVN， 在一些大型的企业也有使用Rational ClearCase的案例， 在一些互联网行业也有组织使用开源免费软件GIT。
分值：1-2分左右
常见考点：
文档分类
配置项及状态
配置管理员
配置权限
版本管理
基线
配置库