软件配置项

软件配置项（SCI）：软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。

定义

一般认为：软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。 软件配置项包括：

①与合同、过程、计划和产品有关的文档和资料；

②源代码、目标代码和可执行代码；

③相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。

软件配置相关

在软件建立时变更是不可避免，而变更又加剧了项目中软件工程师间的混乱。之所以产生混乱，是因为在进行变更前没有仔细分析，或没进行变更控制。Babich曾经这样说过：“协调软件开发使得混乱达到最小的技术叫配置管理。配置管理是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生长率。

软件配置管理，叫SCM，它应用于整个软件工程过程。因为变更在任何时刻都可能发生，因此SCM活动的目标就是为了：

(1)标识变更；

(2)控制变更；

(3)确保变更正确地实现;

(4)向其他有关的人员报告变更。

软件配置管理是贯穿整个软件生存周期的一项技术。它的主要功能是控制软件生存周期中软件的改变，减少各种改变所造成的影响，确保软件产品的质量。正确应用软件配置管理是开发高质量软件所不可缺少的。软件配置管理的过程是软件开发过程中质量管理的精髓。

管理

软件配置项是作为配置项识别活动的产出物，CMMI中要求有文档化的配置项识别准则，根据准则来进行配置项识别，列出配置项列表，给与配置项唯一的编号、名称等，并标明配置项的一些重要属性，如：它的存储位置、它的负责人、对应源码语言、受控级别等。

---

已剪辑自: https://blog.csdn.net/sinat_34905048/article/details/115212463

我们在讨论软件工程化的时候经常会说起配置项这个名词，讨论软件测试时也经常说配置项测试，那到底什么叫配置项？配置项（CI）和软件配置项（CSCI）到底有什么关系？配置项到底应该怎么划分才是合理的？

我们搞技术的，说话要有依据，让我们从国标的定义说起。

首先搞清楚什么是配置项：

在国标《GB/T 11457-2006 信息技术与软件工程术语》里，对这几个概念都有明确的定义：

1. 配置项（configuration item，缩写为CI），是为配置管理设计的硬件、软件或两者的集合。它在配置管理中作为单个实体来对待。
2. 计算机软件配置项（computer software configuration item，缩写为CSCI），是为配置管理设计的软件的集合，在配置管理的过程中，作为单个实体对待。

在《GJB/Z 141-2004军用软件测试指南》中，对软件配置项也有描述：

软件配置项是为独立的配置管理而设计的并且能满足最终用户功能的一组软件。

从配置项的定义可以得出，配置项（CI）和软件配置项（CSCI）是包含与被包含的关系，配置项包括硬件配置项和软件配置项两部分。我们平常在CMMI，GJB5000A和软件测试中通常指的配置项是软件配置项（CSCI）。

从定义可以看出，软件配置项这个概念的引入目的是为了更好的做配置管理，那么什么是软件配置管理？我们再从概念入手，说一说软件（software）、软件配置（software configuration,简称SC）和配置管理（configuration management，简称CM）。

软件：与计算机系统的操作有关的计算机程序、规程和可能相关的文档。

软件配置：软件产品在不同时期的组合，该组合随开发工作的进展而不断的变化。

配置管理：应用技术的和管理的指导和监控的方法以标识和说明配置项的功能和物理特性，控制这些特征的变更，记录和报告变更处理和实现状态，并验证与规定的需求的遵循性。

从软件的定义可以开出，软件并不是说我们通常意义上理解的简单的一个程序，而是包括规约和相关文档。我们常常说的软件测试，不仅指的是被测的程序，还包括涉及的软件需求，设计等文档（被测对象可能还要包括相关的数据，特别是现在的人工智能软件，这一点标准里没有提到），他们共同组成了一个软件实体。为了控制该实体的功能和物理特性与设计期望相一致，我们需要在配置管理中对其特性进行标识、记录与验证。

在配置管理过程中，配置项是作为单个实体来对待的。为了便于理解配置项的定义，就需要搞清楚什么叫做“单个实体”。
任何一篇非独立的文档、数据、规程或者程序，是不是可以作为单个实体？答案是否定的，因为它们只是产品的一部分，单独存在是没有意义的。如果在配置管理中将每一个元素都作为配置项，就会产生配置管理过于繁琐的后果。

这又引出了另外一个问题：如果将一个系统的所有软件都划成一个配置项，或者少划几个配置项，这样管理活动就会少很多，岂不是皆大欢喜？

这样会造成新的问题。配置管理过程的各种审核和管理都是基于配置项的。在配置管理过程中，会采用“锁定”的方法来保证开发过程的统一（这里暂时不考虑分支合并）。当开发人员甲申请对某个配置项进行修改，系统将配管系统中的配置项下发给甲之后，系统应将该配置项进行锁定，避免其他人员在甲更改该配置项的过程中对同一配置项进行更改，该锁定过程会持续到甲完成更改，将内容提交系统后结束。在此期间内，其余人是不能对同一配置项提出更改要求的，否则就会导致版本的混乱。配置管理系统的“取回——锁定——更改——提交并解除锁定”过程，在互联网的很多开源项目中（如Git中的很多项目），是由公共配置管理系统自动控制的，而在很多科研单位，是由配置管理员人工控制的。不论哪种控制方式，配置管理的核心内容就是配置控制，而实现配置控制，合适的控制粒度都是合理控制和高效率开发的基础。所以，将很多软件划到一个配置项是不合适的。

有人可能会说：“我们的配置项都是总体单位定的，总体单位划配置项时，将我们单位分系统中所有软件，大概七八个都划成一个配置项，这是总体定的，所以我们单位的配置管理也只划分了一个配置项。”这种说法是否合理？

从项目的总体方来说，这样的安排没有问题。总体方完全可以在配置管理中将一个分包方的所有软件产品作为一个配置项进行管理。但作为产品的分包承制方，在拿到总体的要求后，应做自己的配置项划分。换句话说，一个项目的配置项划分应该分成不同的层级，越往下配置项划分越细。《GJB 5000A-2008 军用软件研制能力成熟度模型》中也有描述：“工作产品的配置管理可以按照多个粒度级进行实施。”对于总体方，可按照将工程中涉及的软件产品按照适合自己管理的方式划分出若干配置项，而配置项分配到了各级承研单位，应将自己承研的部分再次细化成更小的配置项。承研单位的某一个配置项可以作为该工程承研上级单位的配置部件或配置单元。这就体现了配置管理的多粒度级的特性。

那么如何划分配置项？我们以例子进行说明。

某单位被分配一个分系统研制任务，其软件在总体单位按照一个配置项管理。在此单位组织人员对分系统进行需求分析与设计后，将系统功能设计成A，B两个软件实现。其中A软件由甲工程师负责完成，B软件因为规模较大，由乙和丙两位工程师共同完成。这种情况下，怎么划分配置项才合理？

比较合理的方式是在该单位的组织层面，划分成A软件与B软件两个软件配置项，在课题组内部的配置管理中，将B软件按照乙和丙的分工，划分成两个配置项（或者配置部件）进行多级管理。如果结合传统“三库”管理制度，可以在组织级的受控库和产品库中将A与B划分成两个配置项进行管理，在开发组内部的开发库中将A划分成一个配置项，将B软件划分成两个配置项（配置部件）进行管理。

需要说明的是，GJB5000A里边并又没有软件配置项如何划分作出具体的说明。因此，本文的观点只是在作者从自己的工程经验角度所论述的最佳的定义方法，并不代表GJB5000Ａ的官方解读。