CMMI2.0配置管理工作及访谈学习笔记

Posted 2022-12-16 肖永威

1. 配置管理概述

1.1. 关于配置管理

配置管理是通过技术或其他手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施，通过配置标识、版本控制、版本管理、基线管理和配置审计来管理工作产品的完整性。

配置管理的主要目的是进行工作产品管理，确保产品开发者在软件生命周期中的各个阶段都能得到良好的产品配置。其中包括各类文档、源代码、规范、bug等等。

在CMMI2.0中对配置管理又有新的诠释和变化，例如：去掉了配置状态记录，重点强调了配置控制的方法，将配置控制明确为版本控制和变更控制。再如：对基线的阐述不仅仅有软件基线，2.0也新增了硬件基线，这给软硬件一体项目实施的组织提供了理论基础。

1.1.1. 基本概念与术语

• 配置项：配置管理的对象，主要是指软件全生命周期过程包括各种文档资料，代码等工作产品，例如：给客户的交付物、公司内部指定的输出、采购来的各种产品、构件以及开发需要的各种工具环境等。

• 基线：经过正式认可的、作为后续开发基础的一组配置项，其变更需要经过正式的批准。

• 配置控制委员会（CCB）：对配置项的变更进行评审认可的一个小组。

• 配置审计：检查基线中的配置项版本是否正确一致、位置是否正确、是否与其功能说明一致。

软件配置管理(SCM)是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。

信息系统项目管理师，配置管理包括6个主要活动:制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

1.2. CMMI配置管理实践列表

实践域	序号	原文描述	中文描述
CM	1.1	Perform version control.	执行版本控制
CM	2.1	Identify items to be placed under configuration management.	识别置于配置管理之下的配置项
CM	2.2	Develop, keep updated, and use a configuration and change management system.	建立、保持更新并使用配置和变更管理系统
CM	2.3	Develop or release baselines for internal use or for delivery to the customer.	建立或发布内部使用或交付给客户的基线
CM	2.4	Manage changes to the items under configuration management.	管理配置项的变更
CM	2.5	Develop, keep updated, and use records describing items under configuration management.	建立、保持更新并使用描述了配置项的记录
CM	2.6	Perform configuration audits to maintain the integrity of configuration baselines, changes, and content of the configuration management system.	执行配置审计以维持配置基线、变更和配置管理系统内容的完整性

1.3. 配置库

项目配置管理的库分为开发库、受控库、产品库。这三个库是相互独立的物理库，其中受控库在逻辑上分为配置库和基线库。

三库管理的概念源自CMM/CMMI，即开发库、受控库和产品库。配置项在三库之间迁移，一级比一级的控制更严格。从CMM的角度来看，对开发库的管理并没有要求，但是对受控库和产品库是需要进行管理的。

1.3.1. 开发库

用于存放开始起草的工作产品，目录结构可以按照配置项的类别分为代码和文档，文档可分为需求类、计划类技术类、测试类等，根据项目的实际情况进行确定。开发库由项目组成员使用，对项目组成员没有读写权限的限制。

开发人员在配置项写入时，必须填写注释信息以标识配置项的功能；配置项变更时注明变更理由。

1.3.2. 受控（文档）库

用于存放评审或待测试通过的工作产品。目录结构与开发库保持一致。受控库对项目组成员只有读的权限，配置管理员有读、写、修改的权限。

1.3.3.（受控）基线库

用于存放已发布的基线，目录结构以基线的名称进行划分。基线库对项目组成员只有读的权限，配置管理员有读、写、修改的权限。

1.3.4. 产品库

保存发布基线的配置项。作为最终产品存放在产品库，等待交付客户使用，出入库要严格办理手续。

2. 配置管理流程

2.1. 岗位与职责

2.1.1. 配置管理员（CM）

配置管理员（CM），主要工作内容是组织级资产库存储管理，项目级软件全生命周期过程中的配置项管理，工作内容如下：

• 建立配置库：为项目建立开发库（管理库）、基线库，建立配置库结构并分配权限（命名规范）
• 在每个阶段结束的时候建立基线库，以及变更基线
• 配置库备份，收权限
• 依据软件项目计划、配置管理规程、过程资产库编制配置管理计划
• 配置审计
• 记录CM活动，撰写配置管理周期性工作报告
• 为项目组提供SCM 理论和相关工具的培训，并提供技术支持

2.1.2. 项目经理（PM）

• 批准建立基线
• 批准配置管理计划
• 审批设计、测试、源代码变更申请
• 审批设计、测试、源代码基线变更申请
• 配合QA、CM进行功能配置审计

2.1.3. CCB

• 审批需求、发布变更申请
• 审批需求、发布基线变更申请

2.1.4. QA

• 配合QA、CM进行功能配置审计
• 配置管理审计

2.1.5. 项目组成员

• 每日工作开始，先从开发库（管理库）中检出（拉取/获取）文档和源代码，工作结束，工作产品（文档和源代码）提交到开发库
• 提交准备纳入基线的产品

开发库，包括库中的分支。

2.2. 流程

2.2.1. 配置库管理流程

2.2.2. 基线建立流程

2.2.3. 基线变更管理流程

3. 配置审计/审核

配置审计的⽬的：从技术和管理两个层⾯分别保证产品配置和配置管理过程的完整性与正确性。
配置审计分三种：物理配置审计、功能配置审计、配置管理审计。.

3.1. 物理配置审计

物理配置审计是用以验证所构建的配置项符合技术⽂档中对其的定义和描述。物理审计的时机应该是在⼊受控库之前或建⽴基线之前，因为配置项或基线经审核通过后再受控或再建⽴是合理的，且物理审计的⽬的是验证配置项或基线是否与定义和描述它的⽂档⼀致。

物理审计内容就⾄少应该包括：

• 检查配置项版本标识是否正确；
• 检查⼊库配置项不同版本之间关系是否清楚；
• 检查配置项与基线发布书中的信息是否⼀致；
• 正确版本的源代码、资源、⽂档、安装说明。

3.2. 功能配置审计

功能审计用以验证配置项的开发已经按要求完成，达到了功能或分配基线中规定的功能与质量属性特征，并且操作和⽀持⽂档也已经按要求完成。功能审计的时机是功能或分配基线已经建⽴之后，通常可以在产品基线建⽴之前，且功能审核最主要的⽬的是验证产品是否满⾜需求或者技术协议。

功能审计内容就⾄少应该包括：

• 对照技术协议和需求跟踪矩阵，检查⽤户需求是否被完整的传递和实现，尤其要关注交付物要求；
• 检查是否计划按进⾏了⽂档评审，是否关闭了所有评审问题；
• 检查是否按计划进⾏了软件测试，是否关闭了所有测试问题。

3.3. 配置管理审核：

配置审计是指，在配置标识、配置控制、配置状态记录的基础上对所有配置项的功能及内容进⾏审查，以保证软件配置项的可追溯性。配置管理审核（配置审计）内容包括：

• 检查配置项是否完备，特别是关键的配置项是否遗漏；
• 检查所有配置项的基线是否存在，基线产⽣的条件是否齐全；
• 检查每份技术⽂档作为某个配置项版本的描述是否精确，是否与相关版本⼀致；
• 检查每项已批准的更改是否都已实现；
• 检查每项配置项更改是否按配置更改规程或有关标准进⾏；
• 检查每个配置管理⼈员的职责是否明确，是否尽到了应尽的责任；
• 检查配置信息安全是否收到破坏，评估安全保护机制的有效性。

4. 配置软件工具使用——Git

4.1. Git分支

几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。

有人把 Git 的分支模型称为"必杀技特性"，而正是因为它，将 Git 从版本控制系统家族里区分出来。

• master: 主分支(保护分支)，不能直接在master上进行修改代码和提交；
• develop: 测试分支，所以开发完成需要提交测试的功能合并到该分支；
• feature-*: 新功能开发分支，根据不同需求创建独立的功能分支，开发完成后合并到develop分支；
• hotfix-*: bug修复分支，根据实际情况对已发布的版本进行漏洞修复；
• release-*: 预发布分支。

4.2. Git的工作流程

4.2.1. Git 工作区、暂存区和版本库

• Workspace：工作区，平时存放项目代码的地方。
• Index / Stage：暂存区，用于临时存放改动信息，事实上它只是一个文件，保存即将提交到本地仓库的文件列表信息。
• Repository：仓库区（或本地仓库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本。
• Remote：远程仓库 ，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换。

4.2.2. Git的工作流程

一般工作流程如下：

• 克隆 Git 资源作为工作目录。
• 在克隆的资源上添加或修改文件，也就是在工作目录（Workspace）中添加、修改文件。
• 如果其他人修改了，你可以更新资源。
• 在提交前查看修改。
• 提交修改。
• 在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

4.2.3. 客户端可视化工具

使用Sourcetree客户端工具，直接克隆项目到本地，Sourcetree是用于Windows和Mac终端的免费易用Git客户端。

把经过评审过文档、测试过的源代码，放入工作目录中，再提交、推送到Master分支。

4.3. GitLab用户权限管理

GitLab用户在组中有五种权限：Guest、Reporter、Developer、Master、Owner。

• Guest：可以创建issue、发表评论、不能读写版本库
• Reporter：可以克隆代码，不能提交，QA、PM可以赋予这个权限
• Developer：可以克隆代码、开发、提交、push、RD可以赋予这个权限
• Master：可以创建项目、添加 tag 、保护分支、添加项目成员、编辑项目、核心RD负责人可以赋予这个权限
• Owner：可以设置项目的访问权限-Visibility Level、删除项目、迁移项目、管理组成员、开发组leader可以赋予这个权限

GitLab中的组和项目有三种访问权限：Private、Internal、Public

• private：只有组成员可以看到
• internal：只要登录的用户就能看到
• public：开源的所有的人都可以看到

5. 组织过程改进

CM工作进行总结中，提出改进建议：“需要建立配置管理系统、设定权限，设定配置项标示等过程，依据提供的成熟的模板建立流程”。提交给EPG，由EPG汇总到过程改进建议表中。

建立配置管理系统，以配置项的状态进行划分，并且要考虑到配置项变更管理的流程。配置项的状态分为起草、已检查和已发布3种状态。以下是配置库流转的示意图。

为了有效的进行软件过程改进工作，组织需要建立EPG，负责组织级的软件过程改进活动，使这些活动与各项目协调一致。EPG是过程改进活动的枢纽。

参考：

赛希咨询. CMMI2.0之我见-配置管理CM. 百度. 2022.11
麦哲思科技任甲林. 我说CMMI 2.0 之 配置管理. CSDN博客. 2019.01
菜鸟教程，Git 教程
颜海镜. 图解如何管理Git分支. 知乎. 2022.07
肖永威. Sourcetree git配置实践过程及克隆过程中遇到的问题. CSDN博客. 2021.12