系统集成|第十六章(笔记)

---

上篇：第十五章、采购管理
下篇：第十七章、变更管理

第十六章 信息（文档）和配置管理

---

16.1 文档管理

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

• 概述：是指某种数据媒体和其中所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西。在软件工程中，文档常常用来表示对活动、需求、过程或结果，进行描述、定义、规定、报告或认证的任何书面或图示的信息。
• 《计算机软件产品开发文件编制指南》明确了软件项目文档的具体分类。提出文档从重要性和质量要求方面可以分为非正式文档和正式文档；从项目生命周期可分为开发文档、产品文档、管理文档。

软件文档分类：

• 开发文档
• 产品文档
• 管理文档

质量等级：

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

信息系统文档规范化管理的主要体现：

• 1）文档书写规范

  • 概述：管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。例如，在程序的开始要用统一的格式包含程序名称、程序功能、调用和被调用的程序、程序设计人等。

• 2）图表编号规则

  • 概述：在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则的编号，可以方便图表的查找。图表的编号一般采用分类结构。根据生命周期法的5个阶段，可以给出如右图所示的分类编号规则。根据该规则，就可以通过图表编号判断该图表处于系统开发周期的哪一个阶段，属于哪一个文档，文档中的哪一部分内容及第几张图表。
    

• 3）文档目录编写标准

  • 概述：为了存档及未来使用的方便，应该编写文档目录。管理信息系统的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。文档编号-一般为分类结构，可以采用同图表编号类似的编号规则。文档名称要完整规范。格式或载体指的是原始单据或报表、磁盘文件、磁盘文件打印件、大型图表、重要文件原件、光盘存档等。

• 4）文档管理制度

  • 概述：为了更好地进行信息系统文档的管理，应该建立相应的文档管理制度。文档的管理制度需根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。建立文档的相关规范是指文档书写规范、图表编号规则和文档日录编写标准等。文档的借阅应该进行详细的记录，并且需要考虑借阅人是否有使用权限。在文档中存在商业秘密或技术秘密的情况下，还应注意保密。特别要注意的是，项目干系人签字确认后的文档要与相关联的电子文档一一对应，这些电子文档还应设置为只读。

---

16.2 配置管理

应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求遵循性。

软件配置管理是一组用于在计算机软件的整个生命期内管理变化的活动。

主要活动：

• 制定配制管理计划

  • 概述：配置管理计划是对如何开展项目配置管理工作的规则，是配置管理过程的基础，应该形成文件并在整个项目生命周期内 处于受控状态。配置控制委员会负责审批该计划

• 配置标识

  • 概述：配置标识也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征，配置标识是配置管理员的职能
  • 内容：
    • （1）识别需要受控的配置项；
    • （2）为每个配置项指定唯一性的标识号；
    • （3）定义每个配置项的重要特征；
    • （4）确定每个配置项的所有者及其责任；
    • （5）确定配置项进入配置管理的时间和条件；
    • （6）建立和控制基线；
    • （7）维护文档和组件的修订与产品版本之间的关系。
  • 注意：由配置管理员负责

• 配置控制

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

  • 变更步骤：

    1. 变更申请
    2. 变更评估
    3. 通告评估结果
    4. 变更实施
    5. 变更验证与确认
    6. 变更的发布
    7. 基于配置库的变更控制

    注意：批准变更是 CCB ，实施变更负责是 PM（项目经理）

• 配置状态报告

  • 概述：配置状态报告也称配置状态统计，其任务是有效的记录和管理配置所需要的信息，目的是及时，准确地给 出配置项的当前状况，供相关人员了解，以加强配置管理工作
  • 内容：
    • （1）每个售空配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态
    • （2）每个变更申请的状态和已批准的修改的实施状态
    • （3）每个基线的当前和过去版本的状态以及各版本的比较
    • （4）其他配置管理过程活动的记录
  • 作用：配置状态报告应着重反映当前基线配置项的状态，已向管理者报告系统开发活动的进展情况。配置状态报告应定期进行，并尽量通过 CASE 工具自动生成。

• 配置审计

  • 概述：配置审计也称配置审核或配置评价，包括功能配置审计或物理配置审计，分别用已验证当前配置项一致性和完整性
  • 作用：确保项目配置管理状态的有效性，体现了配置管理的最基本要求
  • 不允许出现的混乱现象：
    • （1）防止向用户提交不适合的产品，如交付了用户手册的不正确版本
    • （2）发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更
    • （3）找出各配置项间不匹配或不相容的现象
    • （4）确认配置项已在所要求的质量控制审核之后纳入基线并入库保存
    • （5）确认记录和文档保持着可追溯性
  • 体现：
    • 功能配置审计（一致性）
      • 验证 ：（1）配置项的开发以完满完成；（2）配置项已达到配置标识中规定的性能和功能特征；（3）配置项的操作和支持文档已完成并且是符合要求的
    • 物理配置审计（完整性）
      • 验证：（1）要交付的配置项是否存在；（2）配置项中是否包含了所有必需的项目

• 发布管理与交付

  • 主要任务：有效控制软件产品和文档的发行和支付，在软件产品的生存期内妥善保存代码和文档的母拷贝
  • 活动：存储、复制、打包、交付、重建

配置项：

• 概述：

  • 为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。
  • 配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。软件配置项分类软件的开发过程是—个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线"这─概念。根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

• 内容：
  （1）外部交付的软件产品和数据
  （2）指定的内部软件工作产品和数据
  （3）指定的用于创建或支持软件产品的支持工具
  （4）供方 / 供应商提供的软件和客户提供的设备 / 软件

• 包括（它们经评审和检查通过后进去配置管理）：

  • 项目计划书
  • 需求文档
  • 源代码
  • 可执行代码
  • 测试用例
  • 运行软件所需的各种数据

• 注意：所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章 节（部分）记录对象的标识信息，在引入配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。

• 分类：

  • 基线配置项
    • 例如：基线配置项可能包括所有的设计文档和源程序等
    • 基本原则：基线配置项向开发人员开放读取的权限
  • 非基线配置项
    • 例如：非基线配置项可能包括项目的各类计划和报告等
    • 基本原则：非基线配置项向 PM，CCB 及相关人员开放

  所有配置项的操作权限应由 CMO（配置管理员）严格管理

• 版本号

  • 规则

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

  • 状态类型：
    • 草稿
      • 依据：配置项刚建立时，其状态为 “草稿”
      • 版本号：版本号格式为 0.YZ。YZ 的数字范围为 01~99，随着草稿的修正 ，YZ 的取值应递增， YZ 的初值和增值由用户自己把握
    • 正式
      • 依据：配置项通过评审后，其状态变为 “正式”；当配置项修改完毕并重新通过评审时，其状态变为 “正式”
      • 版本号：版本号格式为 X.Y,X 为主版本号，取值范围为 1~ 9。Y 为次版本号，取值范围为 0 ~ 9
    • 修改
      • 依据：当配置项发生更改后，其状态变为 “修改”
      • 版本号：的版本格式为 X.YZ。配置项正在修改时，一般指增大 Z 值，X.Y 值保持不变。当配置项修改完毕，状态成为 “正式”时，将 Z 值设置为零，增加 X.Y 值
  • 图示
    

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

• 配置基线

  • 概述：

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

  • 创建基线（发行基线）的主要步骤：
    • 获取CCB的授权
    • 创建构造基线或发行基线
    • 形成文件
    • 使基线可用

• 配置库

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

    • 按配置项类型建库：按配置项类型分类建库，适用于通用软件的开发组织。在这样的组织内，产品的集成性往往较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率 。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一 些不必要的麻烦。

    • 按任务建库：按开发任务建立相应的配置库，适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。

• 配置控制委员会（CCB）

  • 概述：配置控制委员会（CCB）负责对配置变更做出评估，审批以及监督已批准变更的实施。CCB建立在项目级，其成员可以包括项目经理，用户代表，产品经理，开发工程师，测试工程师，质量控制人员，配置管理员等。 CCB 不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的 CCB，小的项目 CCB 可以只有一个人，甚至只是兼职人员。通常，CCB 不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理计划审批，基线设立审批，产品发布审批等。
  • CCB 负责组织对变更申请进行评估并确定的内容：
    • （1）变更对项目的影响
    • （2）变更的内容是否必要
    • （3）变更的范围是否考虑周全
    • （4）变更的实施方案是否可行
    • （5）变更工作量估计是否合理

• 配置管理员（CMO）

  • 概述：负责为每个项目成员分配对配置库的操作权限；负责在项目的整个生命周期中进行配置管理活动
  • 具体配置内容：
    • （1）编写配置管理计划
    • （2）建立和维护配置管理系统
    • （3）建立和维护配置库
    • （4）配置项识别
    • （5）建立和管理基线
    • （6）版本管理和配置控制
    • （7）配置状态报告
    • （8）配置审计
    • （9）发布管理和交付
    • （10）对项目成员进行配置管理培训

• 配置管理系统

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

  配置管理系统在项目范围的应用，包括变更控制过程，实现下列目标。
  (1）建立一种方法，前后一贯地识别与提出对基准的变更请求，并且评估这些变更的价值和有效性。
  (2）通过考虑每一变更的影响，提供改进项目的机
  (3）向项目管理团队提供方法，以前后一致的方式把批准的和拒绝的所有交更告知项目干系人。
  (4）整体变更控制过程里面的一些配置管理括动如下。
  A、配置识别项:是确定与核实产品配置、标记产品与文档、管理变更、以及保持信息公开的基础。
  B、配置状态:当提交配置项的适当数据时，应记录与报告该信息。这个信息包括批准的配置识别项的一个列表、建议变更的状态，以及被批准的变更的执行状态。
  C、配置核实和审计;配置核实和配置审计保证—个项目的配置项的组成，相应的变更被记录、评估、批准、追踪以及正确地执行。这保证了在配置文件中确定的功能已被满足。

构造小组：

• 包括成员：

  • 小组负责人：其对整个构造过程负责。主要职责是协调与其他部门或与上级主管的关系，监督工作进程,协调小组内部关系。
  • 技术支持专家 ：其负责在技术、设备方面为本组提供支持和服务，并负责本组同其他部门就技术问题进行联络，如了解相关项目情况、开发环境和开发人员状况等。
  • 配置管理技术专家：其对配置管理过程的构造和配置管理工具十分熟悉。主要任务是指导配置管理过程的构造，帮助制订配置管理规章，负责对开发人员进行配置管理工具的培训。通常由配置管理工具提供商或专门的配置管理顾问机构的人员担当此任。
  • 配置管理系统用户代表：他们是从将来要在实际的项目开发过程中使用该系统、遵循该过程的开发人员中挑选出来的。他们负责从构造初期了解配置管理系统和规程，根据开发羟验协助制订、修改配置管理规程，并在试验项目中担任部分开发角色。这部分成员应包括软件开发项目经理、设计人员、编码、测试和构造、发布人员。该项目小组成立后，将按后述步骤开展配置管理过程的构造工作。

• 各角色在配置管理活动中的权限：
  

• 配置管理方式：

  • 手工
  • 自主化工具：
    • CVS
      SVN
      GIT
      microsoft vss
      microsoft vss
      merant pvcs
      ca ccc/havest
      perforce
      rationalclearcase

相关说明

基于配置库的变更控制：

• 图例
  

• 配置库分类：

  • 开发库
    • 概述：开发库,也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。
    • 注意：开发库不需要配置管理，所以不需要配置管理员控制
  • 受控库
    • 概述：包含当前的基线及对基线的变更。
  • 产品库
    • 概述：包含已发布的各种基线。

• 流程：

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

---

上篇：第十五章、采购管理
下篇：第十七章、变更管理