软件流程和管理（十）：配置管理
目录
1. 了解配置管理的作用
1.1 什么是软件配置？
1.2 配置管理的作用
2. 了解配置管理过程
2.1 CM Processes
2.2 CM Tasks
3. 理解与配置管理相关的任务
3.1 定义
3.2 版本控制
3.3 CM Tasks
3.4 Change Control
4. 配置审核
4.1 状态报告
1. 了解配置管理的作用
2020年，科尔斯超市对其销售点(POS)系统进行了升级。
- 事情没有按计划进行。
- 一个技术问题意味着4小时内无法付款。
1.1 什么是软件配置？
所有这些人工制品之间都存在着依赖关系：
- 例如，一个代码模块可能依赖于一个设计元素，如类图或状态图，以及一个设计元素，如设计类图。
- 反过来，这些都可能依赖于文本需求、用例和分析类的组合。
1.2 配置管理的作用
问题是变化!
- 如果我们对一个工件做了改变，可能会影响到该工件的所有依赖关系。
- 如果我们不小心，对工件的改变可能会使配置处于不一致的状态。
- 例如，对需求的改变会对系统设计和所有依赖设计的代码模块产生影响。
- 同时，代码的测试计划、测试用例和测试脚本也会受到影响。
- 危险的是，我们可能会改变一个模块而不改变它的一个依赖模块，使配置不一致。
- 例如，对需求的改变会对系统设计和所有依赖设计的代码模块产生影响。
配置管理的目的是在不失去整体一致性的情况下适当管理变化 适当地管理变化，同时又不失去整体的一致性，方法是：
- 建立流程。
- 建立存储库；以及
- 使用其他适当的工具和技术
配置管理（CM）解决以下问题：
- 我们如何管理变更请求？
- 软件组件是什么，在哪里？
- 每个软件组件的状态是什么？
- 对一个组件的改变如何影响其他组件？
- 我们如何解决冲突的变化？
- 我们如何维护多个版本？
- 我们如何保持系统的更新？
2. 了解配置管理过程
2.1 CM Processes
CM的目标：
- 确定所有将共同组成配置的项目
- 管理这些项目中的一个或多个项目的变化，以使该集合保持一致
- 管理产品的不同版本
- 随着配置的不断发展，保证软件的质量
2.2 CM Tasks
识别
- 确定项目所需的配置项目
版本控制
- 选择流程和工具来管理开发中的不同版本的配置项目。
变更控制
- 对影响一个以上的配置项目的变更进行管理。
配置审计
- 检查配置的一致性
配置报告
- 报告配置项目的状态
3. 理解与配置管理相关的任务
3.1 定义
需要配置管理的工件集合称为配置项，配置项：
一个典型的配置项目的清单：
- 需求规格、需求模型、需求规格的部分和个别需求
- 用例、用户故事
- 设计模型、设计文件、设计元素和类设计
- 源代码模块
- 对象代码模块
- 发布模块
- 软件工具
- 测试驱动和存根，以及测试脚本
- 与项目有关的文件或文件的章节
3.2 版本控制
对版本控制系统的要求。
1. 一个用于存储配置项目的存储库
2. 一个版本管理功能，允许软件工程师创建和跟踪版本，并在必要时将系统回滚到以前的版本
- 例如：git、svn、cvs
3. 类似于make的工具，允许工程师将某一特定目标的所有配置对象收集在一起并构建该目标
- 例如：Apache Maven、Apache Ant、make（unix、linux）。
SCM信息被保存在一个存储库或配置数据库中
Version 版本：
一个模型、文件、代码或其他配置项目的实例，在功能上与其他系统实例有某种区别。
Variant 变体：
与版本相同，有非功能上的变化。一个系统的实例，在功能上与其他系统的实例相同，但在功能上没有区别。
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
版本控制
- 选择流程和工具来管理开发中的不同版本的配置项目
- 一个存储所有相关配置对象的项目数据库。
- 一个能存储所有版本的配置对象的版本管理能力。
- 一种使软件工程师能够收集所有相关配置对象的制作设施。
构建软件的特定版本。
变更控制
- 对影响一个以上配置项目的变化进行管理。
- 更改控制是软件生命周期中的手动步骤。它结合了人的程序和自动化工具。
- 提交和评估变更请求，以评估技术优点、潜在的副作用、对其他配置对象和系统功能的整体影响以及变更的项目成本。
3.4 Change Control
变更管理计划
- 整体配置管理计划的一部分，专门控制这些对配置的更改。
- 更改的方式必须让项目组的每个人都能发现。
- 究竟需要做哪些改变
- 他们需要做什么来影响该变化
- 为什么要进行改变
- 它将如何影响他们
更重要的是，在分布式控制结构中，一些变化可能需要仔细协商，以便每个人都理解变化的必要性并支持它。
基线
- 基线是一个稳定的人工制品
- 它已经被正式审查和同意，现在已经为未来的发展做好准备。
- 它只能通过正式的变更管理程序来改变。
4. 配置审核
对其他配置管理活动进行补充，确保存储库中的内容实际上是一致的，所有的改变都是正确的。
4.1 状态报告
- 是大型项目跟踪存储库状态的一种常见方式。
- 这个想法是为了审查配置对象与其他配置对象的一致性。与其他配置对象的一致性，以发现任何遗漏或寻找潜在的副作用。
- 状态报告可以有多种形式，但最常见的目的是报告感兴趣的配置项目的状态和已经实现的基线。
- 例如，我们可能有一个设计元素处于以下状态之一：未启动、初始工作、修改、批准、基线 - 状态报告可以将该状态与项目进度表中的内容进行比较。