研发能力持续成长-配置管理

2024-01-27 理论教育版权反馈

【摘要】：当作者编写完毕并经过审批之后，配置项进入“正式发布”状态，此状态的配置项可供任何项目成员查阅和使用，但任何人不能随意修改，所以有时也称“正式发布”状态为“冻结”状态。基线中的配置项处于“冻结”状态，不能被随意修改，更改必须经过相应的变更控制流程，而且必须通过不同的版本号区分更改前后的配置项。配置管理计划应该在项目计划阶段制定。

开发项目实施过程中会产生许许多多的工作成果，例如文档、程序和数据等。在规模较大的产品开发过程中，一方面软件模块、电子硬件模块、结构零部件等各类组件很多，涉及大量的工作成果，例如软件代码、硬件设计图、相应的设计方案、测试方案、工艺设计方案等；另一方面这些组件的各种工作成果将会快速变化，产生大量版本，因此这些工作成果的版本有可能出现混乱、丢失等问题，影响开发项目顺利实施。所以，这些工作成果都需要保持完整，并保证版本配套，以便项目成员查阅、修改并协同工作。毫无疑问，这些工作成果应该被分门别类、有条理地保存起来。

开发项目的配置管理CM（Configuration Management）就是要保证在产品开发过程中所有工作成果的完整、版本配套，以实现产品开发过程中全体项目成员及其工作成果的协同配合。配置管理的工作目标的表述如下：

1．项目工作成果是已标识的、受控的和适用的。

2．已识别的项目工作成果的更改是受控的。

3．使项目相关成员及时了解产品基线的状态和内容。基线的概念将在本小节下文中介绍。

4．配置管理的各项工作是有计划进行的。

配置管理工作发源于软件开发项目，但是目前已应用到包含硬件的产品开发项目。

开发项目配置管理与产品数据管理、产品配置管理的区别

通常所说的配置管理的完整名称是开发项目配置管理。开发项目的软件代码、硬件设计图等工作成果既要进行开发项目配置管理，又都属于产品数据，那么开发项目配置管理与产品数据管理有何区别呢？

开发项目配置管理的目的是保证开发过程中工作成果的版本配套、完整，因此其核心是版本配置管理。产品数据管理目的是保证开发项目为供应链、销售提供的设计成果完整准确。

在开发项目进入验证阶段之前，各种工作成果的版本处于快速变化之中，因此开发项目配置管理偏重于新产品未进入验证阶段之前，偏重开发项目内部版本管理。

在开发项目进入验证阶段之后，新产品开始进行小批量试生产，因此技术和设计相对成熟，各种工作成果的版本应该是相对稳定的。产品数据管理偏重于新产品进入验证阶段之后，偏重于管理较为稳定的、可在企业范围内应用的开发项目设计成果。

对于软件，开发项目配置管理应管理每一个软件模块，而产品数据管理一般只管理软件产品，不管理模块以下的层次。

因此，开发项目配置管理与产品数据管理是分工协作的关系，而不可互相取代。当然，可以将两者放在同一个部门统一管理。

另外，产品配置管理也是很常见的概念，是指产品功能和部件的灵活配置以适应客户个性化需求，例如电脑的硬盘、内存、CPU、显示屏都可以由客户进行选择、配置。所以，产品配置管理与开发项目配置管理也是不同的概念。

在本小节下文中，除非特别指明，配置管理都是指开发项目配置管理。

配置项、配置标识、配置库、基线

凡是纳入配置管理范畴的开发项目工作成果，可以被统称为配置项CI（Configuration Item）。配置项主要有两大类，第一类是属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。第二类是开发项目过程管理类文档，例如项目计划、评审记录等，这些文档虽然不是产品的组成部分，但是值得保存。

每个配置项的主要属性有名称、编号、分类、文件状态、版本、作者、日期等，这些属性称为配置标识。要进行配置标识，就需要确定配置标识规范，例如配置项命名规则、编号规则、版本规范等。配置标识规范的原则是方便项目成员检索、记忆，同时确保这些规范在开发项目范围内的一致性。

配置项的状态也是一个重要属性。当配置项首次创建、作者正在编写时，配置项处于“草稿”状态。当作者编写完毕并经过审批之后，配置项进入“正式发布”状态，此状态的配置项可供任何项目成员查阅和使用，但任何人不能随意修改，所以有时也称“正式发布”状态为“冻结”状态。配置项处于“正式发布”状态时，若需要进行修改，在开始修改、并按规定重新完成审批之前，配置项进入“修改”状态，此时项目成员应等待配置项的最新版本。

所有配置项都应被保存在一个配置管理软件系统中，形成配置库，方便项目成员检索和使用，并确保不会混淆、丢失。配置库应完整记录配置项及其版本演化过程。常见的配置管理软件有Microsoft的Visual SourceSafe和Rational的ClearCase等，网上有这些软件工具的大量信息。(www.chuimin.cn)

基线（Baseline）由一组配置项组成，这些配置项应通过了规定的评审或审批，已经相对稳定。例如，经过TR1需求评审之后，需求类文档就形成TR1需求基线版本。基线中的配置项处于“冻结”状态，不能被随意修改，更改必须经过相应的变更控制流程，而且必须通过不同的版本号区分更改前后的配置项。

基线的主要属性有名称、标识符、版本、日期等。通常将交付给客户的产品基线称为一个“Release”，在开发过程中的内部联调形成的产品基线则称为一个“Build”。

每一个基线都是其下一步开发工作的出发点和参考点。基线唯一确定了配置项的一个版本。一般情况下，基线在开发项目的各个里程碑（Milestone）处创建。

开发项目的配置库通常可划分为开发库、基线库和产品库。开发库是项目成员的工作空间，其中的配置项始于某一基线，为某一目的开发服务，开发完成后，经过评审回归到基线库。基线库则包括通过评审的各类基线，各类变更申请的记录和统计数据。产品库是某一基线的拷贝，基线库进入对项目外发布阶段形成产品库，例如可用于小批量试生产的基线、可批量生产的基线等都进入产品库。

产品数据来自于基线库。从基线库提取的产品数据，按照产品数据的评审发布流程通过评审后，发布给各部门使用。

配置管理的职责、角色、流程

配置管理的主要工作内容如图6.12所示。

图6.12　配置管理工作内容示意图

配置管理计划的主要内容是开发项目配置管理的工作安排与进度计划、资源需求计划，包括配置管理软硬件资源计划、配置项计划、基线计划、产品发布计划、配置库备份计划等。配置项计划应确定有哪些配置项，以及这些配置项预计的的正式发布时间。基线计划应确定有哪些基线、各个基线包含哪些配置项，以及这些基线预计的建立时间。

配置管理计划应该在项目计划阶段制定。对于小型项目，配置管理较为简单，可不制定单独的配置管理计划，而是融合到总的开发项目计划中。

为了提高配置管理的效率和安全性，开发项目组PDT中应设立专门的配置管理员，由配置管理员制定和执行配置管理计划。配置管理委员会CCB（Configuration Control Board）是配置管理工作的决策机构，其主要职责是审批配置管理计划、审批重大的变更。CCB主任一般由PDT经理担任，成员包括产品系统工程师PSE、产品质量管理工程师PQA、项目其他骨干成员。

配置库管理工作由配置管理员CMO（Configuration Management Officer）负责。配置库管理的工作内容包括设计和创建配置库，并为每个项目成员分配权限，各项目成员根据自己的权限操作配置库，例如从配置库检索、检入、检出配置项等。配置管理员还应定期维护配置库，例如清除垃圾文件、备份配置库等。

制定配置状态报告是配置库管理方面的一项重要工作。配置状态报告以配置库中的操作记录为基础，真实反映各配置项的变化和进展情况，从而也反映了开发项目的进展情况。配置状态报告应定期制定，并发给项目管理层和项目相关成员，供其了解项目进展情况。

版本管理的目的是按照一定的规则保存配置项的所有版本，避免版本丢失或混乱，以便于追溯配置项的版本变迁过程。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来，对配置项的每次修改都将产生新的版本。制定和实施配置项版本编号规则是做好版本管理工作的前提条件。

变更管理的目的是防止配置项被随意修改而导致混乱。在项目开发过程中，配置项发生变更几乎是不可避免的。变更管理的方法是建立并实施变更管理流程，对变更申请、审批、执行、关闭等活动做出统一规定。

修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。当配置项的状态成为“正式发布”后，必须依据“申请－审批－执行变更－再评审－结束”的变更规则执行。当配置项正在按照变更管理流程进行修改时，即进入“修改”状态。

配置审计是一种“过程质量检查”活动，是质量保证的工作职责之一。为了保证项目成员、配置管理员和CCB都遵守配置管理规范，产品质量管理人员要定期审计配置管理工作。例如，检查基线的各配置项版本是否一致，检查基线的配置项是否齐备等都属于配置审计工作。

图6.13是配置管理的工作流程示意图，主要说明在产品开发过程中配置管理各项工作与开发过程的配合关系。

图6.13　配置管理工作流程示意图

研发能力持续成长-配置管理

相关推荐