软件过程与管理：configuration management

configuration management 扮演的角色 / 为什么 CM 很重要

• 2020年，科尔斯超市对他们的销售点(Pos)系统进行了升级。
• 事情并没有按计划进行。 一个技术问题意味着4小时内无法付款。
  

software configuration management

• 首先我们把软件开发过程中的 artefacts （用例图，代码，测试，类图等）都看做根据软件需求产出的产品。
• 这时候如果发生了一些 change，那么这些 artefacts 其实都需要发生对应的变化，而且他们之间还存在 dependencies： 例如，代码模块可能依赖于设计元素，如类图或状态图，以及设计元素，如设计类图。
  
• 因此当我们谈论 software configurations 的时候，我们通常不仅仅谈论代码层面，还有
  • 所有这些 artefacts 以及
  • 他们之间的 dependencies，
  • 和他们当前所处的状态（当前的 use case 可能是 version2， 而 class diagram 可能处于 version3）

role of configuration management

• 如果我们对一个 artifact 进行更改，它可能会影响该 artifact 的所有依赖关系
• 如果我们不小心，那么对 artifact 的更改可能会使 configuration 处于不一致的状态
  • 例如，对需求的更改将对 系统设计和依赖于该设计的所有代码模块 产生影响。
  • 同样，代码的测试计划、测试用例和测试脚本也会受到影响。
  • 危险之处在于，我们可能更改了一个模块，但没有更改其中一个与之相关的模块，从而导致配置不一致。
    
• 对于软件开发的过程，一致性是非常重要的，配置管理的目的是通过以下方法适当地管理 changes，而不丧失整体的一致性:

• 建立流程;
• 设置 repository;
• 使用其他适当的工具和技术

CM 的流程

• 搞清楚目的，才能更好地理解流程

CM 的目的

• 识别共同组成配置的所有项
• 管理对其中一个或多个项的更改，从而使集合保持一致
• 管理产品的不同版本
• 确保随着配置的推移而发展的软件质量

CM 的任务

• identification（识别）：确定项目所需的配置项
• version control（版本控制）：在开发配置项时，选择过程和工具来管理不同版本的配置项
• change control（更改控制）： 管理影响多个配置项的更改
• configuration auditing （配置审计）：检查配置的一致性
• configuration reporting（配置报告）：报告配置项的状态
  

Identification

• 需要配置管理的 artifacts 集合称为配置项
  
• 需求规范，需求模型，需求规范的部分，以及单独的需求
• 用例, 用户故事
• 设计模型、设计文档、设计元素和类设计
• 源代码模块
• 对象代码模块
• 发布模块
• 软件工具
• 测试驱动程序和存根，以及测试脚本
• 与项目相关的文档或文档的部分

Version control

• 用于存储配置项的存储库
• 一种版本管理功能，允许软件工程师创建和跟踪版本，并在必要时将系统回滚到以前的版本
  例如:git, svn, CVS
• 一种类似工具，允许工程师收集特定目标的所有配置对象并构建该目标
  例如:Apache Maven, Apache Ant, make (unix, linux)

• version: 模型、文档、代码或其他配置项的实例，在功能上与其他系统实例在某些方面不同。
• variant: 与 version 相同，只是进行了非功能性更改。一个系统的实例，它在功能上与其他系统实例相同，但在功能上与其他系统实例不同。（一个英文版本，一个中文版本）
• release: 给开发团队之外的用户的系统实例
  

Change control

• 变更控制是软件生命周期中的手动步骤。它结合了人工程序和自动化工具。

• 提交和评估变更请求，以评估技术价值，潜在的副作用，对其他配置对象和系统功能的总体影响，以及保护变更的成本。

Change management plan （变更管理计划）

• 总体 Configuration management 的一部分，专门控制对配置的这些更改。
• 必须以一种让项目团队中的每个人都能发现的方式进行更改:
  • 确切地说需要做出哪些改变
  • 他们需要做什么来影响改变
  • 为什么要做出这样的改变
  • 它将如何影响他们
• 更重要的是，在分布式控制结构中，一些更改可能需要仔细协商，以便每个人都理解更改的需要并支持它。

计划具体步骤

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

Configuration audits

• 通过确保存储库中的内容实际上是一致的，并且所有的更改都已正确地进行，来补充其他配置管理活动
  • 请求和批准的更改是否已经完成?
  • 更改的配置对象是否通过了质量保证测试?
  • 配置项的属性是否匹配变更?
  • 除了请求所要求的以外，是否有任何额外的更改?
  • 配置对象是否满足外部标准要求?
  • 是否每个配置项都有适当的更改日志?

Configuration reporting

• 大型项目跟踪存储库状态的常用方法

• 其思想是检查配置对象与其他配置对象的一致性，以查找任何遗漏或查找潜在的副作用

• 状态报告可以采用多种形式，但最常见的目的是报告感兴趣的配置项的状态和已实现的基线

  • 例如，我们可能有一个处于以下状态中的设计元素：未启动、初始工作、修改、批准、基线化——状态报告可以将状态与项目进度表中的状态进行比较

与 CM 相关的任务（tasks related to CM)