软件流程和管理（十）：配置管理

目录

1. 了解配置管理的作用

1.1  什么是软件配置？

1.2 配置管理的作用

2. 了解 configuration management process 配置管理过程

2.1 CM Processes CM的流程

2.2 CM Tasks

3. 理解与配置管理相关的任务

3.1 Identification 定义

3.2 Version Control 版本控制

3.3 CM Tasks

3.4 Change Control

3.5 Configuration Auditing 配置审核

3.6 Status Reporting 状态报告

---

1. 了解配置管理的作用

2020年，科尔斯超市对其销售点(POS)系统进行了升级。

• 事情没有按计划进行。
• 一个技术问题意味着4小时内无法付款。

1.1  什么是软件配置？

所有这些 artefacts 人工制品之间都存在着 dependencies 依赖关系：

• 首先我们把软件开发过程中的 artefacts（用例图，代码，测试，类图等）都看做根据软件需求产出的产品。
• 例如，一个代码模块可能依赖于一个设计元素，如类图或状态图，以及一个设计元素，如设计类图。
• 这时候如果发生了一些 change，那么这些 artefacts 其实都需要发生对应的变化，而且他们之间还存在 dependencies：例如，代码模块可能依赖于设计元素，如类图或状态图，以及设计元素，如设计类图。 

因此当我们谈论 software configurations 的时候，我们通常不仅仅谈论代码层面，还有

• 所有这些 artefacts
• 他们之间的 dependencies，
• 和他们当前所处的状态（当前的 use case 可能是 version2， 而 class diagram 可能处于 version3）

1.2 配置管理的作用

问题是变化!  

• 如果我们对一个 artifact 做了改变，可能会影响到该 artifact 的所有依赖关系。
• 如果我们不小心，对 artifact 的改变可能会使配置处于不一致的状态。
  • 例如，对需求的改变会对系统设计和所有依赖设计的代码模块产生影响。 
    • 同时，代码的测试计划、测试用例和测试脚本也会受到影响。 
    • 危险的是，我们可能会改变一个模块而不改变它的一个依赖模块，使配置不一致。

配置管理的目的是在不失去整体一致性的情况下适当管理变化 适当地管理变化，同时又不失去整体的一致性，方法是：

• 建立流程。
• 建立存储库；以及
• 使用其他适当的工具和技术

配置管理（CM）解决以下问题：

• 我们如何管理变更请求？
• 软件组件是什么，在哪里？
• 每个软件组件的状态是什么？
• 对一个组件的改变如何影响其他组件？
• 我们如何解决冲突的变化？
• 我们如何维护多个版本？
• 我们如何保持系统的更新？

2. 了解 configuration management process 配置管理过程

2.1 CM Processes CM的流程

CM的目标：

1. 确定所有将共同组成配置的项目
2. 管理这些项目中的一个或多个项目的变化，以使该集合保持一致
3. 管理产品的不同版本
4. 随着配置的不断发展，保证软件的质量

2.2 CM Tasks

Identification 识别

• 确定项目所需的配置项目

Version control 版本控制

• 选择流程和工具来管理开发中的不同版本的配置项目。

Change control 变更控制

• 对影响一个以上的配置项目的变更进行管理。

Configuration auditing 配置审计

• 检查配置的一致性

Configuration reporting 配置报告

• 报告配置项目的状态

3. 理解与配置管理相关的任务

3.1 Identification 定义

需要配置管理的 artifacts 集合称为配置项，configuration items：

• Basic 基本
• Aggregate 集合
• Derived 派生

一个典型的配置项目的清单：

• 需求规格、需求模型、需求规格的部分和个别需求 requirements specifications, requirements models, sections of the requirements specification, and individual requirements
• 用例、用户故事 use-cases, user stories
• 设计模型、设计文件、设计元素和类设计 design models, design documents, design elements, and class designs
• 源代码模块 source code modules
• 目标代码模块 object code modules
• 发布模块 release modules
• 软件工具 software tools
• 测试驱动和存根，以及测试脚本 test drivers and stubs, and test scripts
• 与项目有关的文档或文档的部分 documents or sections of documents associated with the project

3.2 Version Control 版本控制

对版本控制系统的要求：
1. 一个用于存储配置项目的 repository 存储库 
2. 一个 version management function 版本管理功能，允许软件工程师创建和跟踪版本，并在必要时将系统回滚到以前的版本 

• 例如：git、svn、cvs 

3. make-like facility 类似于make的工具，允许工程师将某一特定目标的所有配置对象收集在一起并构建该目标

• 例如：Apache Maven、Apache Ant、make（unix、linux）。

SCM信息被保存在一个存储库或配置数据库中

Version 版本：

• 一个模型、文件、代码或其他配置项目的实例，在功能上与其他系统实例有某种区别。

Variant 变体：

• 与 Version 相同，有非功能上的变化。一个系统的实例，在功能上与其他系统的实例相同，但在功能上没有区别。（一个软件的中英文版本）

Release 发布：
一个系统的实例，它被分配给开发团队之外的用户。

Derivation History 衍生历史：

• 这是一个应用于配置对象的更改记录

每个变化都应记录：

• 所做的改变
• 更改的理由
• 谁做的改变
• 何时实施

在版本库中跟踪版本的一个常用方法是通过版本号：

• 版本（或构建）号可以有不同的含义
• 例如，一个文件的审查版本（主要版本）与未经审查的修改。
• 例如，整数可能是主要修改（1.0，2,0）。小数点可能意味着微小的变化（2.1，2.2）。
• 例如：Ubuntu 20.04, 20.10, 21.04
• 例如：Mac OS X Panther - 10.3, Mac OS X Tiger - 10.4, Mac OS X Leopard - 10.5

使用版本编号标记分支和合并的项目的派生结构

3.3 CM Tasks

Version control 版本控制

选择流程和工具来管理开发中的不同版本的配置项目

• 一个存储所有相关配置对象的项目数据库。
• 一个能存储所有版本的配置对象的版本管理能力。
• 一种使软件工程师能够收集所有相关配置对象的制作设施。
• 构建软件的特定版本。

Change control 变更控制

对影响一个以上配置项目的变化进行管理。

• 更改控制是软件生命周期中的手动步骤。它结合了人的程序和自动化工具。
• 提交和评估变更请求，以评估技术优点、潜在的副作用、对其他配置对象和系统功能的整体影响以及变更的项目成本。

3.4 Change Control

Change Management Plan 变更管理计划 

• 整体配置管理计划的一部分，专门控制这些对配置的更改。
• 更改的方式必须让项目组的每个人都能发现。
  • 究竟需要做哪些改变 
  • 他们需要做什么来影响该变化 
  • 为什么要进行改变 
  • 它将如何影响他们 

更重要的是，在分布式控制结构中，一些变化可能需要仔细协商，以便每个人都理解变化的必要性并支持它。

计划的具体步骤：

发起变革 -> 评估变革 -> 做出变革

Initiate the Change 发起变革

• 为什么要进行改变？
• 需要什么信息来评估该变化？
• 如何评估该变化？

Evaluate the Change 评估变革

• 变化将如何影响配置？
• 哪些人工制品需要改变，它们的依赖性是什么？
• 变化的好处是什么？
• 变化的成本是什么？
• 改变的好处是否超过了改变的成本？
• 谁会受到变化的影响？

Making the Change 做出变革

• 谁将把变革付诸实施？
• 如何管理这一变化？
• 在项目中工作的其他人员将如何理解这一变化？
• 他们将如何被通知这一变化？
• 在项目中工作的人如何知道变化何时完成？

Baseline 基线

• 基线是一个稳定（stable）的人工制品
• 它已经被正式审查和同意，现在已经为未来的发展做好准备。
• 它只能通过正式的变更管理程序（formal change management）来改变。

3.5 Configuration Auditing 配置审核

对其他配置管理活动进行补充，确保存储库中的内容实际上是一致的，所有的改变都是正确的。

通过确保存储库中的内容实际上是一致的，并且所有的更改都已正确地进行，来补充其他配置管理活动：

• 请求和批准的更改是否已经完成?
• 更改的配置对象是否通过了质量保证测试?
• 配置项的属性是否匹配变更?
• 除了请求所要求的以外，是否有任何额外的更改?
• 配置对象是否满足外部标准要求?
• 是否每个配置项都有适当的更改日志?

3.6 Status Reporting 状态报告

• 是大型项目跟踪存储库状态的一种常见方式。
• 这个想法是为了审查配置对象与其他配置对象的一致性。与其他配置对象的一致性，以发现任何遗漏或寻找潜在的副作用。
• 状态报告可以有多种形式，但最常见的目的是报告感兴趣的配置项目的状态和已经实现的基线。
  • 例如，我们可能有一个设计元素处于以下状态之一：未启动、初始工作、修改、批准、基线 - 状态报告可以将该状态与项目进度表中的内容进行比较。