配置管理之配置项识别

配置管理是对工作产品的管理，那么哪些工作产品需要置于项目配置管理之下呢？这些配置项该如何管理呢？本文和大家一起谈谈与此相关的话题。

（1）配置管理(Configuration Management)概念

配置管理(Configuration Management)管理的是“工作产品(WorkProducts)”。

其目的是确保工作产品的”完整性(integrity)”

主要的配置管理方法包括：

• 配置识别Configuration Identification
• 配置控制Configuration Control
• 配置状态Configuration Status Accounting
• 配置审计Configuration Audit

配置管理给项目带来的价值：

• 减低工作损失，并且增加向客户交付正确版本产品的能力。

完整性(Integrity) [Refer from ISO/IEC 25010]

degree to which a system, product or component prevents unauthorized access to, or modificationof, computer programs or data.

（2）那些工作产品需要置于配置管理之下？

配置项的识别准则，需要参照“SUP.8.BP1中要求的配置管理策略中需要定义的<criteria for configuration items>

通常来说，需要纳入项目配置管理的包括：

• 需要交付给客户的工作产品
• 项目各过程活动的输出成果物
• 外部提供的（如：第三方提供的某软件组件及其相关说明文档、客户提供的客户需求等）
• 工具、设备、项目环境等

（3）识别配置项，需要注意什么，以及需要包括哪些必要的信息？

• 首先，识别的配置项，需要按照一定的方式进行分组

通常可以按照过程活动对配置项进行分组，例如：软件需求活动、软件架构设计活动等

•  其次，需要确定如何对配置项进行控制、管理和访问，并描述配置项的重要特征，例如包括：

• 配置项的唯一标识
• 该配置项的责任者或Owner
• 配置项的控制级别：存储控制、版本控制、基线控制
• 存储位置
• 访问权限
• 纳入配置库的时机

（4）如何确定配置项的控制级别？

配置项的控制级别包括”①存储控制”、”②版本控制”、”③基线控制”。

”①存储控制”

存储控制，也可以说对工作产品没有变更控制。主要适用于一些“记录类型的，在创建之后，不会变更的工作产品”，如：会议记录、周报、测试结果、OIL、Risk List等。

”②版本控制”

工作产品需要有版本信息，由工作产品的作者(Author 或 Owner)控制工作产品的变更。

例如：

Test Leader负责编制测试总结报告，Test Leader首先收集信息制作了V0.1版本的测试总结报告，之后根据Test Team对测试总结报告内容的Comments，更新了测试总结报告，形成正式版本V1.0，并发布。

测试总结报告从V0.1 –> V1.0，是完全由Test Leader来控制的。（我的地盘，我做主）

”③基线控制”

基线(Baseline)：经过正式评审，并且在所有该基线影响的相关方之间达成共识的工作产品集合，该集合成为后续进一步开发的基础，基线在建立之后，需要走正式的变更流程在获得受影响相关方的同意后，才能进行变更。

在项目中，常见的用于基线控制的工作产品包括：

• 各层次的需求，如：相关方需求、系统需求、软件需求、硬件需求等
• 各层次的设计，如：系统设计、软件架构设计、软件详细设计、硬件设计、原理图等
• 软件实现，如：软件源代码

（5）确定配置项的控制级别时，常见的一些讨论：

1）项目计划，需要进行基线管理吗？

首先，项目计划类工作产品，可以进行基线管理。

但：基线控制主要是与产品设计开发（工程类活动）相关的工作产品，这些工程类工作产品的相关方是整个项目团队，如果不进行严格的变更控制，会有很大的项目开发风险。

“项目计划”是项目经理与相关方（客户、组织、项目成员）等达成一致的，关于实施项目的计划安排。项目计划发生变更时，根据变更的影响，由项目经理来控制项目计划的变更、让相关方参与Review和批准，是可以接受的。

2）测试用例，可以不进行基线管理吗？

回答这个问题，需要依赖上下文信息。

场景1：

• 独立的测试团队，负责测试用例的设计，和测试实施
• 测试用例通过评审之后，形成了测试用例V1.0版本
• 测试实施过程中，发现测试用例有不足，需要修改
• 【方式1】：如果测试用例是采用基线管理的方式，则测试用例的变更需要走正式的变更流程，变更需要批准之后才能实施。
• 【方式2】：如果测试用例是采用版本管理的方式，则测试用例的Owner，也就是测试团队，自行控制测试用例的变更，将其更新为V1.1版本。

采用基线管理的【方式1】，需要哪些基线受影响的相关方来评审和批准变更呢？

不采用基线管理的【方式2】，会有什么风险吗？

场景2：

• 测试设计团队，负责测试用例的设计
• 设计好的测试用例在获得了测试设计团队和测试实施团队的共同Review，达成共识后，形成V1.0版本，发布给测试实施团队。（测试用例是测试实施的基础）

在这种场景下，测试用例采用基线管理，还是版本管理呢？

是否采用基线管理，建议从以下几个方面考虑：

（1）该工作产品的受影响方有哪些？有没有除了工作产品Owner之外的其它团队需要基于该工作产品来开展工作。

（2）如果采用版本管理，只有Owner来控制工作产品的变更，有什么风险吗？

推荐阅读：

• ​​ASPICE VDA Guideline解读(19)：SUP.8 配置管理​​
• ​​Automotive SPICE和Automotive SPICE评估的那些事​​
• ​​如何达到并维持Automotive SPICE能力度级别​​
• ​​浅谈Automotive SPICE Level 3​​
• ​​​截至2020年1月：上海先起之仨人谈起公众号文章合集下载！​​

文章转载自公众号：仨人谈起